\documentclass[a4paper,oneside]{book}

\pagestyle{myheadings}

%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Pacotes para acentua??o %
%%%%%%%%%%%%%%%%%%%%%%%%%%%

\usepackage[T1]{fontenc}
\usepackage{ae}
\usepackage[ansinew]{inputenc}
\usepackage{enumerate}


%%%%%%%%%%%

\usepackage[brazil]{babel}
\usepackage{unicode} % Acentos Português, compatibilizando o Windows com o texto


\usepackage{graphicx}

%%%%%%%%%%%


\linespread{1.5} % espa?amento entre linhas


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%              Formata??o da P?gina                  %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

% horizontal
\setlength{\hoffset}{-1in}

\setlength{\oddsidemargin}{3.0cm} 

\setlength{\textwidth}{160mm} % (210mm - 30mm - 20mm)

\setlength{\parindent}{1.25cm} % identa??o de cada par?grafo

% vertical
\setlength{\voffset}{-1in}
\addtolength{\voffset}{2.0cm}

\setlength{\topmargin}{0.0cm}

\setlength{\headheight}{5mm}
\setlength{\headsep}{5mm}

\setlength{\textheight}{247mm} % (297mm - 30mm - 20mm)

%\setlength{\footskip}{0mm}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\usepackage{amsmath}
\usepackage{amsfonts}
\usepackage{amssymb}
\usepackage{listings}
\usepackage{color}


\definecolor{gray92}{gray}{.92}
\definecolor{gray75}{gray}{.75}
\definecolor{gray45}{gray}{.45}
\definecolor{orange}{RGB}{255,128,0}
\definecolor{blue}{RGB}{0,0,255}
\definecolor{Snow}{RGB}{255,250,250}                    
\definecolor{GhostWhite}{RGB}{248,248,255}              
\definecolor{WhiteSmoke}{RGB}{245,245,245}              
\definecolor{Gainsboro}{RGB}{220,220,220}               
\definecolor{FloralWhite}{RGB}{255,250,240}             
\definecolor{OldLace}{RGB}{253,245,230}                 
\definecolor{Linen}{RGB}{250,240,230}                   
\definecolor{AntiqueWhite}{RGB}{250,235,215}            
\definecolor{PapayaWhip}{RGB}{255,239,213}              
\definecolor{BlanchedAlmond}{RGB}{255,235,205}          
\definecolor{Bisque}{RGB}{255,228,196}                  
\definecolor{PeachPuff}{RGB}{255,218,185}               
\definecolor{NavajoWhite}{RGB}{255,222,173}             
\definecolor{Moccasin}{RGB}{255,228,181}                
\definecolor{Cornsilk}{RGB}{255,248,220}                
\definecolor{Ivory}{RGB}{255,255,240}                   
\definecolor{LemonChiffon}{RGB}{255,250,205}            
\definecolor{Seashell}{RGB}{255,245,238}                
\definecolor{Honeydew}{RGB}{240,255,240}                
\definecolor{MintCream}{RGB}{245,255,250}               
\definecolor{Azure}{RGB}{240,255,255}                   
\definecolor{AliceBlue}{RGB}{240,248,255}               
\definecolor{lavender}{RGB}{230,230,250}                
\definecolor{LavenderBlush}{RGB}{255,240,245}           
\definecolor{MistyRose}{RGB}{255,228,225}               
\definecolor{White}{RGB}{255,255,255}                   
\definecolor{Black}{RGB}{0,0,0}                         
\definecolor{DarkSlateGray}{RGB}{47,79,79}              
\definecolor{DimGrey}{RGB}{105,105,105}                 
\definecolor{SlateGrey}{RGB}{112,128,144}               
\definecolor{LightSlateGray}{RGB}{119,136,153}          
\definecolor{Grey}{RGB}{190,190,190}                    
\definecolor{LightGray}{RGB}{211,211,211}               
\definecolor{MidnightBlue}{RGB}{25,25,112}              
\definecolor{NavyBlue,(Navy)}{RGB}{0,0,128}             
\definecolor{CornflowerBlue}{RGB}{100,149,237}          
\definecolor{DarkSlateBlue}{RGB}{72,61,139}             
\definecolor{SlateBlue}{RGB}{106,90,205}                
\definecolor{MediumSlateBlue}{RGB}{123,104,238}         
\definecolor{LightSlateBlue}{RGB}{132,112,255}          
\definecolor{MediumBlue}{RGB}{0,0,205}                  
\definecolor{RoyalBlue}{RGB}{65,105,225}                
\definecolor{Blue}{RGB}{0,0,255}                        
\definecolor{DodgerBlue}{RGB}{30,144,255}               
\definecolor{DeepSkyBlue}{RGB}{0,191,255}               
\definecolor{SkyBlue}{RGB}{135,206,235}                 
\definecolor{LightSkyBlue}{RGB}{135,206,250}            
\definecolor{SteelBlue}{RGB}{70,130,180}                
\definecolor{LightSteelBlue}{RGB}{176,196,222}          
\definecolor{LightBlue}{RGB}{173,216,230}               
\definecolor{PowderBlue}{RGB}{176,224,230}              
\definecolor{PaleTurquoise}{RGB}{175,238,238}           
\definecolor{DarkTurquoise}{RGB}{0,206,209}             
\definecolor{MediumTurquoise}{RGB}{72,209,204}          
\definecolor{Turquoise}{RGB}{64,224,208}                
\definecolor{Cyan}{RGB}{0,255,255}                      
\definecolor{LightCyan}{RGB}{224,255,255}               
\definecolor{CadetBlue}{RGB}{95,158,160}                
\definecolor{MediumAquamarine}{RGB}{102,205,170}        
\definecolor{Aquamarine}{RGB}{127,255,212}              
\definecolor{DarkGreen}{RGB}{0,100,0}                   
\definecolor{DarkOliveGreen}{RGB}{85,107,47}            
\definecolor{DarkSeaGreen}{RGB}{143,188,143}            
\definecolor{SeaGreen}{RGB}{46,139,87}                  
\definecolor{MediumSeaGreen}{RGB}{60,179,113}           
\definecolor{LightSeaGreen}{RGB}{32,178,170}            
\definecolor{PaleGreen}{RGB}{152,251,152}               
\definecolor{SpringGreen}{RGB}{0,255,127}               
\definecolor{LawnGreen}{RGB}{124,252,0}                 
\definecolor{Green}{RGB}{0,255,0}                       
\definecolor{Chartreuse}{RGB}{127,255,0}                
\definecolor{MediumSpringGreen}{RGB}{0,250,154}         
\definecolor{GreenYellow}{RGB}{173,255,47}              
\definecolor{LimeGreen}{RGB}{50,205,50}                 
\definecolor{YellowGreen}{RGB}{154,205,50}              
\definecolor{ForestGreen}{RGB}{34,139,34}               
\definecolor{OliveDrab}{RGB}{107,142,35}                
\definecolor{DarkKhaki}{RGB}{189,183,107}               
\definecolor{Khaki}{RGB}{240,230,140}                   
\definecolor{PaleGoldenrod}{RGB}{238,232,170}           
\definecolor{LightGoldenrodYellow}{RGB}{250,250,210}    
\definecolor{LightYellow}{RGB}{255,255,224}             
\definecolor{Yellow}{RGB}{255,255,0}                    
\definecolor{Gold}{RGB}{255,215,0}                      
\definecolor{LightGoldenrod}{RGB}{238,221,130}          
\definecolor{goldenrod}{RGB}{218,165,32}                
\definecolor{DarkGoldenrod}{RGB}{184,134,11}            
\definecolor{RosyBrown}{RGB}{188,143,143}               
\definecolor{IndianRed}{RGB}{205,92,92}                 
\definecolor{SaddleBrown}{RGB}{139,69,19}               
\definecolor{Sienna}{RGB}{160,82,45}                    
\definecolor{Peru}{RGB}{205,133,63}                     
\definecolor{Burlywood}{RGB}{222,184,135}               
\definecolor{Beige}{RGB}{245,245,220}                   
\definecolor{Wheat}{RGB}{245,222,179}                   
\definecolor{SandyBrown}{RGB}{244,164,96}               
\definecolor{Tan}{RGB}{210,180,140}                     
\definecolor{Chocolate}{RGB}{210,105,30}                
\definecolor{Firebrick}{RGB}{178,34,34}                 
\definecolor{Brown}{RGB}{165,42,42}                     
\definecolor{DarkSalmon}{RGB}{233,150,122}              
\definecolor{Salmon}{RGB}{250,128,114}                  
\definecolor{LightSalmon}{RGB}{255,160,122}             
\definecolor{Orange}{RGB}{255,165,0}                    
\definecolor{DarkOrange}{RGB}{255,140,0}                
\definecolor{Coral}{RGB}{255,127,80}                    
\definecolor{LightCoral}{RGB}{240,128,128}              
\definecolor{Tomato}{RGB}{255,99,71}                    
\definecolor{OrangeRed}{RGB}{255,69,0}                  
\definecolor{Red}{RGB}{255,0,0}                         
\definecolor{HotPink}{RGB}{255,105,180}                 
\definecolor{DeepPink}{RGB}{255,20,147}                 
\definecolor{Pink}{RGB}{255,192,203}                    
\definecolor{LightPink}{RGB}{255,182,193}               
\definecolor{PaleVioletRed}{RGB}{219,112,147}           
\definecolor{Maroon}{RGB}{176,48,96}                    
\definecolor{MediumVioletRed}{RGB}{199,21,133}          
\definecolor{VioletRed}{RGB}{208,32,144}                
\definecolor{Magenta}{RGB}{255,0,255}                   
\definecolor{Violet}{RGB}{238,130,238}                  
\definecolor{Plum}{RGB}{221,160,221}                    
\definecolor{Orchid}{RGB}{218,112,214}                  
\definecolor{MediumOrchid}{RGB}{186,85,211}             
\definecolor{DarkOrchid}{RGB}{153,50,204}               
\definecolor{DarkViolet}{RGB}{148,0,211}                
\definecolor{BlueViolet}{RGB}{138,43,226}               
\definecolor{Purple}{RGB}{160,32,240}                   
\definecolor{MediumPurple}{RGB}{147,112,219}            
\definecolor{Thistle}{RGB}{216,191,216}                 
\definecolor{Snow1}{RGB}{255,250,250}                   
\definecolor{Snow2}{RGB}{238,233,233}                   
\definecolor{Snow3}{RGB}{205,201,201}                   
\definecolor{Snow4}{RGB}{139,137,137}                   
\definecolor{Seashell1}{RGB}{255,245,238}               
\definecolor{Seashell2}{RGB}{238,229,222}               
\definecolor{Seashell3}{RGB}{205,197,191}               
\definecolor{Seashell4}{RGB}{139,134,130}               
\definecolor{AntiqueWhite1}{RGB}{255,239,219}           
\definecolor{AntiqueWhite2}{RGB}{238,223,204}           
\definecolor{AntiqueWhite3}{RGB}{205,192,176}           
\definecolor{AntiqueWhite4}{RGB}{139,131,120}           
\definecolor{Bisque1}{RGB}{255,228,196}                 
\definecolor{Bisque2}{RGB}{238,213,183}                 
\definecolor{Bisque3}{RGB}{205,183,158}                 
\definecolor{Bisque4}{RGB}{139,125,107}                 
\definecolor{PeachPuff1}{RGB}{255,218,185}              
\definecolor{PeachPuff2}{RGB}{238,203,173}              
\definecolor{PeachPuff3}{RGB}{205,175,149}              
\definecolor{PeachPuff4}{RGB}{139,119,101}              
\definecolor{NavajoWhite1}{RGB}{255,222,173}            
\definecolor{NavajoWhite2}{RGB}{238,207,161}            
\definecolor{NavajoWhite3}{RGB}{205,179,139}            
\definecolor{NavajoWhite4}{RGB}{139,121,94}             
\definecolor{LemonChiffon1}{RGB}{255,250,205}           
\definecolor{LemonChiffon2}{RGB}{238,233,191}           
\definecolor{LemonChiffon3}{RGB}{205,201,165}           
\definecolor{LemonChiffon4}{RGB}{139,137,112}           
\definecolor{Cornsilk1}{RGB}{255,248,220}               
\definecolor{Cornsilk2}{RGB}{238,232,205}               
\definecolor{Cornsilk3}{RGB}{205,200,177}               
\definecolor{Cornsilk4}{RGB}{139,136,120}               
\definecolor{Ivory1}{RGB}{255,255,240}                  
\definecolor{Ivory2}{RGB}{238,238,224}                  
\definecolor{Ivory3}{RGB}{205,205,193}                  
\definecolor{Ivory4}{RGB}{139,139,131}                  
\definecolor{Honeydew1}{RGB}{240,255,240}               
\definecolor{Honeydew2}{RGB}{224,238,224}               
\definecolor{Honeydew3}{RGB}{193,205,193}               
\definecolor{Honeydew4}{RGB}{131,139,131}               
\definecolor{LavenderBlush1}{RGB}{255,240,245}          
\definecolor{LavenderBlush2}{RGB}{238,224,229}          
\definecolor{LavenderBlush3}{RGB}{205,193,197}          
\definecolor{LavenderBlush4}{RGB}{139,131,134}          
\definecolor{MistyRose1}{RGB}{255,228,225}              
\definecolor{MistyRose2}{RGB}{238,213,210}              
\definecolor{MistyRose3}{RGB}{205,183,181}              
\definecolor{MistyRose4}{RGB}{139,125,123}              
\definecolor{Azure1}{RGB}{240,255,255}                  
\definecolor{Azure2}{RGB}{224,238,238}                  
\definecolor{Azure3}{RGB}{193,205,205}                  
\definecolor{Azure4}{RGB}{131,139,139}                  
\definecolor{SlateBlue1}{RGB}{131,111,255}              
\definecolor{SlateBlue2}{RGB}{122,103,238}              
\definecolor{SlateBlue3}{RGB}{105,89,205}               
\definecolor{SlateBlue4}{RGB}{71,60,139}                
\definecolor{RoyalBlue1}{RGB}{72,118,255}               
\definecolor{RoyalBlue2}{RGB}{67,110,238}               
\definecolor{RoyalBlue3}{RGB}{58,95,205}                
\definecolor{RoyalBlue4}{RGB}{39,64,139}                
\definecolor{Blue1}{RGB}{0,0,255}                       
\definecolor{Blue2}{RGB}{0,0,238}                       
\definecolor{Blue3}{RGB}{0,0,205}                       
\definecolor{Blue4}{RGB}{0,0,139}                       
\definecolor{DodgerBlue1}{RGB}{30,144,255}              
\definecolor{DodgerBlue2}{RGB}{28,134,238}              
\definecolor{DodgerBlue3}{RGB}{24,116,205}              
\definecolor{DodgerBlue4}{RGB}{16,78,139}               
\definecolor{SteelBlue1}{RGB}{99,184,255}               
\definecolor{SteelBlue2}{RGB}{92,172,238}               
\definecolor{SteelBlue3}{RGB}{79,148,205}               
\definecolor{SteelBlue4}{RGB}{54,100,139}               
\definecolor{DeepSkyBlue1}{RGB}{0,191,255}              
\definecolor{DeepSkyBlue2}{RGB}{0,178,238}              
\definecolor{DeepSkyBlue3}{RGB}{0,154,205}              
\definecolor{DeepSkyBlue4}{RGB}{0,104,139}              
\definecolor{SkyBlue1}{RGB}{135,206,255}                
\definecolor{SkyBlue2}{RGB}{126,192,238}                
\definecolor{SkyBlue3}{RGB}{108,166,205}                
\definecolor{SkyBlue4}{RGB}{74,112,139}                 
\definecolor{LightSkyBlue1}{RGB}{176,226,255}           
\definecolor{LightSkyBlue2}{RGB}{164,211,238}           
\definecolor{LightSkyBlue3}{RGB}{141,182,205}           
\definecolor{LightSkyBlue4}{RGB}{96,123,139}            
\definecolor{SlateGray1}{RGB}{198,226,255}              
\definecolor{SlateGray2}{RGB}{185,211,238}              
\definecolor{SlateGray3}{RGB}{159,182,205}              
\definecolor{SlateGray4}{RGB}{108,123,139}              
\definecolor{LightSteelBlue1}{RGB}{202,225,255}         
\definecolor{LightSteelBlue2}{RGB}{188,210,238}         
\definecolor{LightSteelBlue3}{RGB}{162,181,205}         
\definecolor{LightSteelBlue4}{RGB}{110,123,139}         
\definecolor{LightBlue1}{RGB}{191,239,255}              
\definecolor{LightBlue2}{RGB}{178,223,238}              
\definecolor{LightBlue3}{RGB}{154,192,205}              
\definecolor{LightBlue4}{RGB}{104,131,139}              
\definecolor{LightCyan1}{RGB}{224,255,255}              
\definecolor{LightCyan2}{RGB}{209,238,238}              
\definecolor{LightCyan3}{RGB}{180,205,205}              
\definecolor{LightCyan4}{RGB}{122,139,139}              
\definecolor{PaleTurquoise1}{RGB}{187,255,255}          
\definecolor{PaleTurquoise2}{RGB}{174,238,238}          
\definecolor{PaleTurquoise3}{RGB}{150,205,205}          
\definecolor{PaleTurquoise4}{RGB}{102,139,139}          
\definecolor{CadetBlue1}{RGB}{152,245,255}              
\definecolor{CadetBlue2}{RGB}{142,229,238}              
\definecolor{CadetBlue3}{RGB}{122,197,205}              
\definecolor{CadetBlue4}{RGB}{83,134,139}               
\definecolor{Turquoise1}{RGB}{0,245,255}                
\definecolor{Turquoise2}{RGB}{0,229,238}                
\definecolor{Turquoise3}{RGB}{0,197,205}                
\definecolor{Turquoise4}{RGB}{0,134,139}                
\definecolor{Cyan1}{RGB}{0,255,255}                     
\definecolor{Cyan2}{RGB}{0,238,238}                     
\definecolor{Cyan3}{RGB}{0,205,205}                     
\definecolor{Cyan4}{RGB}{0,139,139}                     
\definecolor{DarkSlateGray1}{RGB}{151,255,255}          
\definecolor{DarkSlateGray2}{RGB}{141,238,238}          
\definecolor{DarkSlateGray3}{RGB}{121,205,205}          
\definecolor{DarkSlateGray4}{RGB}{82,139,139}           
\definecolor{Aquamarine1}{RGB}{127,255,212}             
\definecolor{Aquamarine2}{RGB}{118,238,198}             
\definecolor{Aquamarine3}{RGB}{102,205,170}             
\definecolor{Aquamarine4}{RGB}{69,139,116}              
\definecolor{DarkSeaGreen1}{RGB}{193,255,193}           
\definecolor{DarkSeaGreen2}{RGB}{180,238,180}           
\definecolor{DarkSeaGreen3}{RGB}{155,205,155}           
\definecolor{DarkSeaGreen4}{RGB}{105,139,105}           
\definecolor{SeaGreen1}{RGB}{84,255,159}                
\definecolor{SeaGreen2}{RGB}{78,238,148}                
\definecolor{SeaGreen3}{RGB}{67,205,128}                
\definecolor{SeaGreen4}{RGB}{46,139,87}                 
\definecolor{PaleGreen1}{RGB}{154,255,154}              
\definecolor{PaleGreen2}{RGB}{144,238,144}              
\definecolor{PaleGreen3}{RGB}{124,205,124}              
\definecolor{PaleGreen4}{RGB}{84,139,84}                
\definecolor{SpringGreen1}{RGB}{0,255,127}              
\definecolor{SpringGreen2}{RGB}{0,238,118}              
\definecolor{SpringGreen3}{RGB}{0,205,102}              
\definecolor{SpringGreen4}{RGB}{0,139,69}               
\definecolor{Green1}{RGB}{0,255,0}                      
\definecolor{Green2}{RGB}{0,238,0}                      
\definecolor{Green3}{RGB}{0,205,0}                      
\definecolor{Green4}{RGB}{0,139,0}                      
\definecolor{Chartreuse1}{RGB}{127,255,0}               
\definecolor{Chartreuse2}{RGB}{118,238,0}               
\definecolor{Chartreuse3}{RGB}{102,205,0}               
\definecolor{Chartreuse4}{RGB}{69,139,0}                
\definecolor{OliveDrab1}{RGB}{192,255,62}               
\definecolor{OliveDrab2}{RGB}{179,238,58}               
\definecolor{OliveDrab3}{RGB}{154,205,50}               
\definecolor{OliveDrab4}{RGB}{105,139,34}               
\definecolor{DarkOliveGreen1}{RGB}{202,255,112}         
\definecolor{DarkOliveGreen2}{RGB}{188,238,104}         
\definecolor{DarkOliveGreen3}{RGB}{162,205,90}          
\definecolor{DarkOliveGreen4}{RGB}{110,139,61}          
\definecolor{Khaki1}{RGB}{255,246,143}                  
\definecolor{Khaki2}{RGB}{238,230,133}                  
\definecolor{Khaki3}{RGB}{205,198,115}                  
\definecolor{Khaki4}{RGB}{139,134,78}                   
\definecolor{LightGoldenrod1}{RGB}{255,236,139}         
\definecolor{LightGoldenrod2}{RGB}{238,220,130}         
\definecolor{LightGoldenrod3}{RGB}{205,190,112}         
\definecolor{LightGoldenrod4}{RGB}{139,129,76}          
\definecolor{LightYellow1}{RGB}{255,255,224}            
\definecolor{LightYellow2}{RGB}{238,238,209}            
\definecolor{LightYellow3}{RGB}{205,205,180}            
\definecolor{LightYellow4}{RGB}{139,139,122}            
\definecolor{Yellow1}{RGB}{255,255,0}                   
\definecolor{Yellow2}{RGB}{238,238,0}                   
\definecolor{Yellow3}{RGB}{205,205,0}                   
\definecolor{Yellow4}{RGB}{139,139,0}                   
\definecolor{Gold1}{RGB}{255,215,0}                     
\definecolor{Gold2}{RGB}{238,201,0}                     
\definecolor{Gold3}{RGB}{205,173,0}                     
\definecolor{Gold4}{RGB}{139,117,0}                     
\definecolor{Goldenrod1}{RGB}{255,193,37}               
\definecolor{Goldenrod2}{RGB}{238,180,34}               
\definecolor{Goldenrod3}{RGB}{205,155,29}               
\definecolor{Goldenrod4}{RGB}{139,105,20}               
\definecolor{DarkGoldenrod1}{RGB}{255,185,15}           
\definecolor{DarkGoldenrod2}{RGB}{238,173,14}           
\definecolor{DarkGoldenrod3}{RGB}{205,149,12}           
\definecolor{DarkGoldenrod4}{RGB}{139,101,8}            
\definecolor{RosyBrown1}{RGB}{255,193,193}              
\definecolor{RosyBrown2}{RGB}{238,180,180}              
\definecolor{RosyBrown3}{RGB}{205,155,155}              
\definecolor{RosyBrown4}{RGB}{139,105,105}              
\definecolor{IndianRed1}{RGB}{255,106,106}              
\definecolor{IndianRed2}{RGB}{238,99,99}                
\definecolor{IndianRed3}{RGB}{205,85,85}                
\definecolor{IndianRed4}{RGB}{139,58,58}                
\definecolor{Sienna1}{RGB}{255,130,71}                  
\definecolor{Sienna2}{RGB}{238,121,66}                  
\definecolor{Sienna3}{RGB}{205,104,57}                  
\definecolor{Sienna4}{RGB}{139,71,38}                   
\definecolor{Burlywood1}{RGB}{255,211,155}              
\definecolor{Burlywood2}{RGB}{238,197,145}              
\definecolor{Burlywood3}{RGB}{205,170,125}              
\definecolor{Burlywood4}{RGB}{139,115,85}               
\definecolor{Wheat1}{RGB}{255,231,186}                  
\definecolor{Wheat2}{RGB}{238,216,174}                  
\definecolor{Wheat3}{RGB}{205,186,150}                  
\definecolor{Wheat4}{RGB}{139,126,102}                  
\definecolor{Tan1}{RGB}{255,165,79}                     
\definecolor{Tan2}{RGB}{238,154,73}                     
\definecolor{Tan3}{RGB}{205,133,63}                     
\definecolor{Tan4}{RGB}{139,90,43}                      
\definecolor{Chocolate1}{RGB}{255,127,36}               
\definecolor{Chocolate2}{RGB}{238,118,33}               
\definecolor{Chocolate3}{RGB}{205,102,29}               
\definecolor{Chocolate4}{RGB}{139,69,19}                
\definecolor{Firebrick1}{RGB}{255,48,48}                
\definecolor{Firebrick2}{RGB}{238,44,44}                
\definecolor{Firebrick3}{RGB}{205,38,38}                
\definecolor{Firebrick4}{RGB}{139,26,26}                
\definecolor{Brown1}{RGB}{255,64,64}                    
\definecolor{Brown2}{RGB}{238,59,59}                    
\definecolor{Brown3}{RGB}{205,51,51}                    
\definecolor{Brown4}{RGB}{139,35,35}                    
\definecolor{Salmon1}{RGB}{255,140,105}                 
\definecolor{Salmon2}{RGB}{238,130,98}                  
\definecolor{Salmon3}{RGB}{205,112,84}                  
\definecolor{Salmon4}{RGB}{139,76,57}                   
\definecolor{LightSalmon1}{RGB}{255,160,122}            
\definecolor{LightSalmon2}{RGB}{238,149,114}            
\definecolor{LightSalmon3}{RGB}{205,129,98}             
\definecolor{LightSalmon4}{RGB}{139,87,66}              
\definecolor{Orange1}{RGB}{255,165,0}                   
\definecolor{Orange2}{RGB}{238,154,0}                   
\definecolor{Orange3}{RGB}{205,133,0}                   
\definecolor{Orange4}{RGB}{139,90,0}                    
\definecolor{DarkOrange1}{RGB}{255,127,0}               
\definecolor{DarkOrange2}{RGB}{238,118,0}               
\definecolor{DarkOrange3}{RGB}{205,102,0}               
\definecolor{DarkOrange4}{RGB}{139,69,0}                
\definecolor{Coral1}{RGB}{255,114,86}                   
\definecolor{Coral2}{RGB}{238,106,80}                   
\definecolor{Coral3}{RGB}{205,91,69}                    
\definecolor{Coral4}{RGB}{139,62,47}                    
\definecolor{Tomato1}{RGB}{255,99,71}                   
\definecolor{Tomato2}{RGB}{238,92,66}                   
\definecolor{Tomato3}{RGB}{205,79,57}                   
\definecolor{Tomato4}{RGB}{139,54,38}                   
\definecolor{OrangeRed1}{RGB}{255,69,0}                 
\definecolor{OrangeRed2}{RGB}{238,64,0}                 
\definecolor{OrangeRed3}{RGB}{205,55,0}                 
\definecolor{OrangeRed4}{RGB}{139,37,0}                 
\definecolor{Red1}{RGB}{255,0,0}                        
\definecolor{Red2}{RGB}{238,0,0}                        
\definecolor{Red3}{RGB}{205,0,0}                        
\definecolor{Red4}{RGB}{139,0,0}                        
\definecolor{DeepPink1}{RGB}{255,20,147}                
\definecolor{DeepPink2}{RGB}{238,18,137}                
\definecolor{DeepPink3}{RGB}{205,16,118}                
\definecolor{DeepPink4}{RGB}{139,10,80}                 
\definecolor{HotPink1}{RGB}{255,110,180}                
\definecolor{HotPink2}{RGB}{238,106,167}                
\definecolor{HotPink3}{RGB}{205,96,144}                 
\definecolor{HotPink4}{RGB}{139,58,98}                  
\definecolor{Pink1}{RGB}{255,181,197}                   
\definecolor{Pink2}{RGB}{238,169,184}                   
\definecolor{Pink3}{RGB}{205,145,158}                   
\definecolor{Pink4}{RGB}{139,99,108}                    
\definecolor{LightPink1}{RGB}{255,174,185}              
\definecolor{LightPink2}{RGB}{238,162,173}              
\definecolor{LightPink3}{RGB}{205,140,149}              
\definecolor{LightPink4}{RGB}{139,95,101}               
\definecolor{PaleVioletRed1}{RGB}{255,130,171}          
\definecolor{PaleVioletRed2}{RGB}{238,121,159}          
\definecolor{PaleVioletRed3}{RGB}{205,104,137}          
\definecolor{PaleVioletRed4}{RGB}{139,71,93}            
\definecolor{Maroon1}{RGB}{255,52,179}                  
\definecolor{Maroon2}{RGB}{238,48,167}                  
\definecolor{Maroon3}{RGB}{205,41,144}                  
\definecolor{Maroon4}{RGB}{139,28,98}                   
\definecolor{VioletRed1}{RGB}{255,62,150}               
\definecolor{VioletRed2}{RGB}{238,58,140}               
\definecolor{VioletRed3}{RGB}{205,50,120}               
\definecolor{VioletRed4}{RGB}{139,34,82}                
\definecolor{Magenta1}{RGB}{255,0,255}                  
\definecolor{Magenta2}{RGB}{238,0,238}                  
\definecolor{Magenta3}{RGB}{205,0,205}                  
\definecolor{Magenta4}{RGB}{139,0,139}                  
\definecolor{Orchid1}{RGB}{255,131,250}                 
\definecolor{Orchid2}{RGB}{238,122,233}                 
\definecolor{Orchid3}{RGB}{205,105,201}                 
\definecolor{Orchid4}{RGB}{139,71,137}                  
\definecolor{Plum1}{RGB}{255,187,255}                   
\definecolor{Plum2}{RGB}{238,174,238}                   
\definecolor{Plum3}{RGB}{205,150,205}                   
\definecolor{Plum4}{RGB}{139,102,139}                   
\definecolor{MediumOrchid1}{RGB}{224,102,255}           
\definecolor{MediumOrchid2}{RGB}{209,95,238}            
\definecolor{MediumOrchid3}{RGB}{180,82,205}            
\definecolor{MediumOrchid4}{RGB}{122,55,139}            
\definecolor{DarkOrchid1}{RGB}{191,62,255}              
\definecolor{DarkOrchid2}{RGB}{178,58,238}              
\definecolor{DarkOrchid3}{RGB}{154,50,205}              
\definecolor{DarkOrchid4}{RGB}{104,34,139}              
\definecolor{Purple1}{RGB}{155,48,255}                  
\definecolor{Purple2}{RGB}{145,44,238}                  
\definecolor{Purple3}{RGB}{125,38,205}                  
\definecolor{Purple4}{RGB}{85,26,139}                   
\definecolor{MediumPurple1}{RGB}{171,130,255}           
\definecolor{MediumPurple2}{RGB}{159,121,238}           
\definecolor{MediumPurple3}{RGB}{137,104,205}           
\definecolor{MediumPurple4}{RGB}{93,71,139}             
\definecolor{Thistle1}{RGB}{255,225,255}                
\definecolor{Thistle2}{RGB}{238,210,238}                
\definecolor{Thistle3}{RGB}{205,181,205}                
\definecolor{Thistle4}{RGB}{139,123,139}                
\definecolor{grey11}{RGB}{28,28,28}                     
\definecolor{grey21}{RGB}{54,54,54}                     
\definecolor{grey31}{RGB}{79,79,79}                     
\definecolor{grey41}{RGB}{105,105,105}                  
\definecolor{grey51}{RGB}{130,130,130}                  
\definecolor{grey61}{RGB}{156,156,156}                  
\definecolor{grey71}{RGB}{181,181,181}                  
\definecolor{gray81}{RGB}{207,207,207}                  
\definecolor{gray91}{RGB}{232,232,232}                  
\definecolor{DarkGrey}{RGB}{169,169,169}                
\definecolor{DarkBlue}{RGB}{0,0,139}                    
\definecolor{DarkCyan}{RGB}{0,139,139}                  
\definecolor{DarkMagenta}{RGB}{139,0,139}               



\lstdefinestyle{xml_source_code}
{ 
%		numbers=left, 
%		stepnumber=5,
		language=XML,
		basicstyle=\footnotesize, 
		captionpos = b,  %bottom
		keywordstyle=\color[rgb]{0,0,1},
        commentstyle=\color[rgb]{0.133,0.545,0.133},
        stringstyle=\color[rgb]{0.627,0.126,0.941},
        backgroundcolor=\color{gray92},
     	frame=lrtb,
     	framerule=0.2pt,
     	linewidth = \textwidth
}

\lstdefinestyle{c_source_code}
{ 
%		numbers=left, 
%		stepnumber=5,
		language=c,
		basicstyle=\footnotesize, 
		captionpos = b,  %bottom
		keywordstyle=\color[rgb]{0,0,1},
        commentstyle=\color[rgb]{0.133,0.545,0.133},
        stringstyle=\color[rgb]{0.627,0.126,0.941},
        backgroundcolor=\color{gray92},
     	frame=lrtb,
     	framerule=0.2pt,
     	linewidth = \textwidth
}

\lstdefinestyle{js_source_code}
{ 
%		numbers=left, 
%		stepnumber=5,
		language=javascript,
		basicstyle=\footnotesize, 
		captionpos = b,  %bottom
		keywordstyle=\color[rgb]{0,0,1},
        commentstyle=\color[rgb]{0.133,0.545,0.133},
        stringstyle=\color[rgb]{0.627,0.126,0.941},
        backgroundcolor=\color{gray92},
     	frame=lrtb,
     	framerule=0.2pt,
     	linewidth = \textwidth
}

\lstdefinestyle{html_source_code}
{ 
%		numbers=left, 
%		stepnumber=5,
		language=HTML,
		basicstyle=\footnotesize, 
		captionpos = b,  %bottom
		keywordstyle=\color[rgb]{0,0,1},
        commentstyle=\color[rgb]{0.133,0.545,0.133},
        stringstyle=\color[rgb]{0.627,0.126,0.941},
        backgroundcolor=\color{gray92},
     	frame=lrtb,
     	framerule=0.2pt,
     	linewidth = \textwidth
}



\begin{document}


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%   Comece a cortar aqui  !!!   %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%                  Capa do Template                  %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

%\begin{titlepage}
% \noindent 
% \rule{\textwidth}{1ex} \\ [1ex]
% \begin{center}
%  {\Large \textsc{Universidade Federal Fluminense} } \\ [1.5ex]
%  {\Large \textsc{Centro Tecnológico} } \\ [1.5ex]
%  {\Large \textsc{Instituto de Computação} }  \\ [1.5ex]
%  {\Large \textsc{Curso de Ciência da Computação} } \\ [1.5ex] \vfill  
%  {\Huge Gerador Automático de Stubs em AJAX}
%  \vfill {\Large Autores: Gabriel Affonso Baims \& João Arthur Beekhuizen Nogueira}
%  \\ [1.5ex] {\Large Orientador: Prof. Luiz Carlos Castro Guedes} \\ [3ex]
%  {\Large Niterói-RJ} \\ [1.5ex]
%  {\Large Julho / 2010}
% \end{center}\vspace{1ex}
% \rule{\textwidth}{1ex}
%\end{titlepage}


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%                    Apresenta??o                  %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\pagenumbering{gobble}
% retira a numera??o da p?gina at? quem um novo \pagenumbering{} seja usado

%\part*{ {\huge Parte I} \\[1ex] Apresenta??o}
% utilizamos asterisco para que "Parte" nao seja inserida no sum?rio

%\chapter*{Modelo para elaboração de monografia}

% Este documento foi desenvolvido pelo grupo PET-Tele a fim de orientar
% todos aqueles que estiverem produzindo uma monografia utilizando o
% editor de texto LaTeX.
% 
% Nele, ? apresentada a formata??o necess?ria para a elabora??o da
% monografia, segundo os padr?es da Universidade Federal Fluminense,
% bem como algumas dicas para a edi??o de seu texto.

%A formata??o segue as orienta??es encontradas em
%\textbf{\textit{Apresenta??o de Trabalhos Monogr?ficos de Conclus?o de Curso}, 
%        8a. edi??o revisada, 
%        Estela dos Santos Abreu e Jos? Carlos Abreu Teixeira, 
%        EdUFF, Niter?i, Rio de Janeiro, 2005.
%       }

%As dicas foram originaram-se nas seguintes publica??es: 
%1) \textbf{\textit{Metologia do Trabalho Cient?fico},
%        Ant?nio J. Severino, 
%        22a. edi??o, revista (de acordo com a ABNT) e ampliada,
%        7a. reimpress?o,
%        Cortez Editora, S?o Paulo, SP, 2006
%       }
%e
%2)
%\textbf{\textit{Como se faz uma tese},
%        Umberto Eco,
%        20a. edi??o,
%        Editora Perspectiva, S?o Paulo, SP, 2005.
%       }

%\bigskip
%\begin{flushright}
%\textbf{Grupo PET-Tele}
%\end{flushright}


%\thispagestyle{empty}
%\pagebreak

%\thispagestyle{empty}

%\part*{ {\huge Parte II} \\[1ex] Modelo de Monografia para a Gradua??o}

%\thispagestyle{empty}
%\pagebreak

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%   Pare de cortar  aqui !!!   %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%                  Capa da Monografia                %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\begin{titlepage}
  \begin{center}
    \Large{\textsc{Universidade Federal Fluminense} \\
           \textsc{Instituto de Computação} \\
           \textsc{Departamento de Ciência da Computação} 
          }
    \par\vfill
    \LARGE{Gabriel Affonso Baims} \\
    \LARGE{João Arthur Beekhuizen Nogueira}
    \par\vfill
%    \bigskip
    \LARGE{Gerador Automático de Stubs para JavaScript}
    \par\vfill
    \Large{Niterói-RJ\\2010}
  \end{center}
\end{titlepage}



%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%                Numeracao em romano                 %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\pagenumbering{roman}
\setcounter{page}{2}



%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%                   Folha de Rosto                   %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%


\begin{center}

GABRIEL AFFONSO BAIMS \\
JOÃO ARTHUR BEEKHUIZEN NOGUEIRA

\vfill

GERADOR AUTOMÁTICO DE STUBS PARA JAVASCRIPT

\vspace{3.0cm}

\begin{flushright}
\begin{minipage}{0.50\textwidth}

Dissertação apresentada ao Departamento de Ciência da Computação da
Universidade Federal Fluminense como parte dos requisitos para obtenção do Grau
de Bacharel em Ciência da Computação.

\end{minipage}
\end{flushright}

\vspace{3.0cm}

Orientador: Prof. Dr. LUIZ CARLOS CASTRO GUEDES

\vfill

Niterói-RJ\\2010

\end{center}

\newpage

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%                 Folha de Aprova??o                 %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\begin{center}

GABRIEL AFFONSO BAIMS \\
JOÃO ARTHUR BEEKHUIZEN NOGUEIRA

\vspace{1.0cm}

GERADOR AUTOMÁTICO DE STUBS PARA JAVASCRIPT

\vspace{1.0cm}

\begin{flushright}
\begin{minipage}{0.50\textwidth}

Dissertação apresentada ao Departamento de Ciência da Computação da
Universidade Federal Fluminense como parte dos requisitos para obtenção do Grau
de Bacharel em Ciência da Computação.

\end{minipage}
\end{flushright}

\vfill

\begin{flushleft}

Aprovada em julho de 2010.

\end{flushleft}

\vfill

BANCA EXAMINADORA

\vfill

\hrulefill \\Prof. Dr. LUIZ CARLOS CASTRO GUEDES -
Orientador\\UFF\\

\vfill

\hrulefill \\Prof. CARLOS ALBERTO SOARES RIBEIRO\\UFF\\

\vfill

\hrulefill \\Prof. Dr. ISABEL L. CAFEZEIRO\\UFF\\

\vfill

Niterói-RJ\\2010

\end{center}

\newpage

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%	               Dedicat?ria                     %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

%\begin{flushright}
%\begin{minipage}{0.5\textwidth}

%\vspace{15.0cm} % espa?o do topo at? o in?cio da dedicat?ria 

%Espa?o reservado para a dedicat?ria.

%\end{minipage}
%\end{flushright}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%	              Agradecimentos                   %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\chapter*{Agradecimentos}
\addcontentsline{toc}{chapter}{Agradecimentos}

\thispagestyle{myheadings}

\noindent

%Espaço reservado para os agradecimentos.

Agradecimento 1.

Agradecimento 2.

...

Agradecimento N.

%Os agradecimentos devem ser sucintos e espec?ficos
%a cada tipo de ajuda, a cada id?ia relevante, 
%a cada empr?stimo significativo, pois um agradecimento
%?, de certa forma, um cr?dito dado a algu?m \cite{norma:esjo2005}.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%                  Lista de Ilustra??es                %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\listoffigures
\addcontentsline{toc}{chapter}{Lista de Figuras}

\thispagestyle{myheadings}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%                   Lista de Tabelas                   %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\listoftables
\addcontentsline{toc}{chapter}{Lista de Tabelas}

\thispagestyle{myheadings}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%                       Sum?rio                        %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\tableofcontents

\thispagestyle{myheadings}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%            Resumo na l?ngua vern?cula            %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\chapter*{Resumo}
\addcontentsline{toc}{chapter}{Resumo}

\thispagestyle{myheadings}

Atualmente existem geradores de stubs para Web Services, voltados para
aplicações web e feitos com linguagens como Java e frameworks como .NET. Essas por sua
vez têm como principal foco aplicações mais robustas e de grande porte. Com
isso, desenvolvedores menos experientes que desejem utilizar WebServices em
aplicações web mais simples enfrentam um grau de dificuldade maior adaptando
a sua aplicação para uma nova plataforma. O intuito desse projeto é desenvolver
um gerador automático de stubs em JavaScript, que é uma linguagem nativa da
web, dando assim mais uma opção para o desenvolvedor criar aplicativos que se
comuniquem com Web Services, com a finalidade de simplificar a construção de
sites de menor porte.\\

\begin{flushleft}
\textbf{Palavras-chave:}\\
Gerador Automático de Stubs, WebService, JavaScript. 
\end{flushleft}


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%                      Abstract                      %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\chapter*{Abstract}
\addcontentsline{toc}{chapter}{Abstract}

\thispagestyle{myheadings}

Currently exist stubs generators for webservices, directed to web applications
and made with languages like Java and frameworks like .NET, whose main focus are
applications more robust and huge. Thus, less experienced developers who want
to use webservices in a simple web aplications, face a greater degree of
difficulty to adapt their application to a new platform. The purpose of this
project is develop an automatic stubs generator for JavaScript, which is a web
native language, thus providing an additional option for the developers to
create applications that communicate with Web Services, in order to simplify the
construction of smaller sites.\\
 
\begin{flushleft}
\textbf{Keywords:}\\ 
Automatic Stubs Generator, WebService, JavaScript.
\end{flushleft}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%                Numeracao em arabico                %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\pagebreak
\pagenumbering{arabic}



%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%                        Texto                         %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\chapter{Introdução}
\thispagestyle{empty} % retira numeracao da pagina, conforme as normas de apresentacao.

\section{Descrição do problema}

Construir um gerador automático de stubs em JavaScript através da tradução de um
arquivo WSDL.

\section{Motivação}

A falta de um gerador de stubs voltado para sistemas menores faz com que um
desenvolvedor que queira utilizar uma ferramenta de trabalho mais simples para
montar uma página web, que utilize os serviços expostos por Web Services, seja
obrigado a utilizar ferramentas mais complexas, que têm o principal foco em
sistemas maiores. O intuito desse projeto é desenvolver um gerador automático
de stubs para JavaScript, que é uma linguagem nativa da web, dando assim mais
uma opção para o desenvolvedor criar aplicativos que se comuniquem com
Web Services, com a finalidade de simplificar a construção de sites de menor
porte.

\section{Proposta de trabalho}

Estudar e entender o que são, para que servem e como se comportam os
Web Services. Analisar como é feita a troca de mensagens entre o cliente e
o servidor e a partir disso definir uma estratégia de montagem de um stub a
partir da tradução de um WSDL, utilizando a linguagem Java para construir stubs
em JavaScript.

\chapter{Fundamentos}

\section{Web Services}
\index{parágrafo}
Web Services é uma solução utilizada na integração de sistemas. É uma 
tecnologia baseada na exposição de serviços por meio da troca de mensagens
padronizadas, fazendo com que sistemas construídos em plataformas distintas
sejam compatíveis. Os Web Services trocam informações por meio de mensagens,
normalmente em formato XML e empacotadas pelo protocolo SOAP (Simple Object
Access Protocol), para que seja possível que cada aplicação tenha a sua própria
``linguagem'' desde que se faça uma tradução para uma linguagem universal, o
formato XML.

	Essencialmente, os Web Services fazem com que os recursos da aplicação do
software estejam disponíveis sobre a rede de uma forma normalizada. Existe uma grande
tendência à utilização dessa tecnologia, pois possibilita que diferentes
aplicações comuniquem-se entre si e utilizem recursos diferentes.

Os Web Services são identificados por um URI (Unique Resource Identifier),
descritos e definidos usando WSDL (Web Service Description Language), que é um
arquivo escrito em XML que contém toda a descrição dos serviços expostos. Um
dos motivos que tornam os Web Services atrativos é o fato de este modelo ser
baseado em tecnologias padrões, em particular XML e HTTP.

\section{Padrão}
A arquitetura de Web Services é baseada em três padrões: SOAP, WSDL e UDDI. 

\subsection{SOAP (Simple Object Access Protocol)}
Define os mecanismos de como é feito a chamada de Web Services e como os dados
são retornados. Os SOAP clients podem chamar métodos dos SOAP services passando
objetos no formato XML. SOAP é um protocolo leve para a troca de informações em
um ambiente distribuído descentralizado. É um protocolo baseado em XML dividido
em três partes: Um envelope que define a estrutura que descreve o que está
dentro da mensagem e como processá-la; um conjunto de regras de codificação para
expressar a definição dos tipos de dados e a convenção para as chamadas remotas
de procedimentos (RPC). Veremos mais a fundo esse padrão no capítulo III.

\subsection{WSDL (Web Service Description Language)}
Descreve a interface externa dos Web Services permitindo com que desenvolvedores
possam criar clientes capazes de realizar chamadas remotas aos serviços
oferecidos. É um XML para descrever os serviços de rede como um conjunto de
parâmetros operacionais nas mensagens. As operações e mensagens são descritas
abstratamente e então ligadas a um protocolo de rede e a um formato de mensagem
concreto para definir um parâmetro. Parâmetros concretos relacionados são
combinados em parâmetros abstratos (serviços). O WSDL é extensível para permitir
descrição dos parâmetros e suas mensagens, independentemente de qual formato da
mensagem ou protocolo de rede é usado para se comunicar. Veremos mais a fundo
esse padrão no capítulo III.

\subsection{UDDI (Universal Discovery, Description and Integration)}
É um protocolo para web baseado em registros e que contém informações sobre os
Web Services incluindo o endereço dos arquivos WSDL e dos serviços ativos. Um
registro para um Web Service provê informações técnicas para permitir que um
desenvolvedor possa criar aplicativos clientes capazes de se ligarem ao serviço
e chamarem os métodos. 

\section{Integração de Sistemas}
O conceito de Web Services tem sido cada vez mais utilizado nos ambientes
empresariais. A arquitetura orientada a serviços (SOA) ganha cada vez mais
espaço como ferramenta de integração de sistemas. Uma abordagem muito utilizada
de SOA seria o barramento de serviços em que aplicações expõem seus serviços no
barramento e as aplicações clientes chamam o barramento para utilizar esses
serviços ao invés de fazer uma chamada a cada aplicação servidora. Esse tipo de
abordagem possibilita a criação de workflows que utilizam mais de um serviço,
formando um macro serviço, o que possibilita até mesmo a união de serviços de
diferentes aplicações servidoras.

\section{Vantagens}
No modelo de Web Services, cada sistema atua como um componente independente na
arquitetura de integração. Todas as interfaces, transformações de dados e
comunicações entre componentes são baseados em padrões abertos e vastamente
adotados, independentes de fornecedores e plataformas. Com isso a utilização, de
Web Services como ferramenta de integração de sistemas nas empresas se torna
mais atraente. Os principais pontos que justificam a adoção desse tipo de
integração são:


\begin{itemize}
 \item{\textbf{Simplicidade}: é mais simples de se implementar que as
soluções tradicionais.}
 \item{\textbf{Padrões abertos}: utilizam padrões abertos como HTTP, SOAP,
 UDDI, em invés de tecnologias proprietárias;}
 \item{\textbf{Flexibilidade}: alterações nos componentes são muito mais simples
para o sistema como um todo do que alterações nos adaptadores tradicionais;}
\item{\textbf{Custo}: as soluções tradicionais são muito mais caras;}
\item{\textbf{Escopo}: cada sistema pode ser tratado de maneira individual, já
que para integrá-lo basta implementar uma camada que o encapsule. Na abordagem
tradicional, todos os sistemas devem ser tratados ao mesmo tempo, já que farão
parte da mesma solução monolítica de integração. }
\end{itemize}

\chapter {Tecnologias Utilizadas}

\section{XML}\label{XML}

XML é o acrônimo de Extensible Markup Language e foi desenhada para transportar
e armazenar dados. Assim como o HTML o XML também é uma linguagem de marcação,
com a diferença de não ter sido criada para exibir dados. As tags do XML não são
pré-definidas tendo que ser definidas pelo próprio desenvolvedor, pode-se
observar então que é uma linguagem que foi desenhada para ser auto descritiva.

Apesar de ser uma linguagem, o XML não faz nenhuma ação, apenas estrutura,
armazena e transporta informação. No exemplo abaixo, podemos ver um
bilhete da Dani para o Tom:


\begin{lstlisting}[style=XML_source_code]
<Bilhete>
  <Para>Tom</Para>
  <De>Dani</De>
  <Titulo>Lembrar</Titulo>
  <Mensagem>Não se esqueça de mim essa semana!</Mensagem>
</Bilhete>

\end{lstlisting}


Podemos perceber que ele é muito descritivo, pois possui informações de
remetente e destinatário, um título e o corpo da mensagem. São apenas
informações encapsuladas por tags que precisam de algum pedaço de software para
serem enviadas, recebidas ou exibidas.

Apesar do XML ser apenas um texto simples, aplicações que sabem lidar com essa
tecnologia são capazes de lidar com as tags de forma especial. O significado
funcional das tags depende da natureza da aplicação.

É importante perceber que o XML não é um substituto para o HTML e sim um
complemento, pois como vimos acima, o XML é utilizado para transportar dados
enquanto o HTML é utilizado para exibí-los.

O XML simplifica o compartilhamento e transporte de dados, pois como é um texto
simples, aplicações com tipos de dados incompatíveis podem acessar os dados
armazenados em um arquivo XML e compreender o que está representado neste
arquivo. Com isso, reduz-se drasticamente a complexidade de se trocar dados
entre sistemas, inclusive por meio da internet.



\subsection{Estrutura}

O XML possui uma estrutura de árvore, começando no nó raiz e passando pelos
ramos até as folhas. O exemplo abaixo ilustra um arquivo XML com um nó raiz
<bilhete>, quatro nós que são filhos diretos do nó raiz e um nó <Observacao>
que é um sub-filho do nó raiz e filho direto do nó <mensagem>.\\


\begin{lstlisting}[style=XML_source_code]
<Bilhete>
  <Para>Tom</Para>
  <De>Dani</De>
  <Titulo>Lembrete</Titulo>
  <Mensagem>Não se esqueça de mim essa semana!
    <Observacao>Me deve um jantar</Observacao>
  </Mensagem>
</Bilhete>
\end{lstlisting}


Todo documento XML precisa ter elemento raiz, que é o pai de todos os outros
elementos. Os termos Pai, Filho e Irmão são usados para descrever o
relacionamento entre os elementos. Todo Pai possui um filho, e filhos no mesmo
nível da árvore são considerados irmãos e todos os elementos podem ter filhos.


A figura \ref{fig:XMLTree} exemplifica a relação entre os elementos de um documento XML no
qual todos podem ter atributos ou texto, assim como em um documento HTML.

\begin{figure}[h]
    \centering
    \includegraphics[width=90mm]{figuras/XMLTree.png}
    \caption{Relação de elementos XML}
    \label{fig:XMLTree}
 \end{figure}

\subsection{Sintaxe}
As regras de sintaxe de um documento XML são relativamente simples como pode ser
visto abaixo:


\begin{itemize}
   \item {Todo documento XML precisa ter elemento raiz.}
   \item {Todo elemento XML precisa ter uma tag fechando.}
   \item {As Tags XML são Case Sensitives.}
   \item {Os elementos precisam estar aninhados corretamente.}
   \item {Os valores dos atributos precisam estar entre aspas “”.}
   \item {Caracteres como ``<'' precisam ser substituídos por referências de
entidades, para evitar erros de interpretação do parser.}
   \begin{table}[h]
	\centering
		\begin{tabular}{|c|c|}
		  \hline
		    Referenciais de Entidades & Caracteres \\ \hline
		   \&lt;  &  < \\ \hline
		   \&gt;  &  > \\ \hline
           \&amp; &  \& \\ \hline
           \&após; &  ' \\ \hline
           \&quot; &  '' \\ \hline
		\end{tabular}
		\caption{Tabela de Caracteres especiais}
\end{table}
   
    \item {O comentário é similar com o HTML <!-- Comentário -->}
\end{itemize}

\subsection{Simple Types}\label{Simple Types}

Um elemento simples é um elemento XML que contém apenas texto. Ele não pode
conter nenhum outro elemento nem atributo. Entretanto, a restrição de “apenas
texto” é enganadora. O texto pode ser de diferentes tipos, dentre eles os
definidos pelo XML  Schema (boolean, string, date, etc.), ou pode ser definido
pelo usuário. Pode ainda conter restrições para que um tipo de dado esteja
contido dentro de um limite ou requerer que o dado seja compatível com um padrão
específico. A sintaxe para definir um elemento simples é vista abaixo:

\begin{lstlisting}[style = XML_source_code] 
<xs:element name="xxx" type="yyy"/>
\end{lstlisting}

Em que XXX é o nome do elemento e YYY é o tipo de dado do elemento. O exemplo
abaixo mostra alguns elementos  XML e suas respectivas definições como simple
type: 
\begin{lstlisting}[style = XML_source_code] 
<xs:element name="lastname"type="xs:string"/> 
<xs:element name="age" type="xs:integer"/>
<xs:element name="dateborn" type="xs:date"/>

<lastname>Refsnes</lastname>
<age>36</age>
<dateborn>1970-03-27</dateborn>
\end{lstlisting}

Os elementos simples podem ter valores default ou fixos especificados na
declaração. No exemplo abaixo vemos o elemento ``color'' e o elemento
“University”. Como pode-se observar, se não for
passado nenhum valor para o elemento ``color'', o mesmo será vermelho. Já o
elemento ``Univertsity" será sempre UFF.

\begin{lstlisting}[style = XML_source_code] 
<xs:element name="color" type="xs:string" default="red"/> 
<xs:element name="University" type="xs:string" fixed="UFF"/>
\end{lstlisting}

OS elementos simples não podem ter atributos, pois se tiverem, passam a ser
 considerados elementos complexos. Porém um atributo é sempre declarado como um
 tipo simples. Além das opções de valores fixos e padrão, atributos também
 podem ser opcionais ou obrigatórios. Abaixo, vemos um atributo configurado como
 obrigatório, caso queira que seja opcional, é só não usar a cláusula ``use''.

 \begin{lstlisting}[style = XML_source_code] 
<xs:attribute name="lang" type="xs:string" use="required"/>
\end{lstlisting}

Quando um elemento ou atributo XML possui um tipo de dado definido, acaba tendo
uma restrição sobre o conteúdo do elemento ou atributo. Se um elemento XML for
do tipo “xs:date” e contiver a string “Hello World”, o elemento não vai ser
válido. Com XML Schemas, pode-se definir restrições próprias para os elementos
e atributos XML. As restrições são usadas para definir valores aceitáveis para
um elemento ou atributo XML. O exemplo abaixo define um elemento chamado de
``age'' com restrição. O valor da idade não pode ser menor que 0 nem maior que
120.

\begin{lstlisting}[style = XML_source_code]
<xs:element name="age">
  <xs:simpleType>
    <xs:restriction base="xs:integer">
      <xs:minInclusive value="0"/>
      <xs:maxInclusive value="120"/>
    </xs:restriction>
  </xs:simpleType>
</xs:element>
\end{lstlisting}

Para limitar o conteúdo de um elemento XML para um conjunto de valores aceitos,
pode-se usar uma restrição de enumeração. O exemplo abaixo ilustra o elemento
``car'' com uma restrição de aceitar apenas os valores: Audi, Golf, BMW.

\begin{lstlisting}[style = XML_source_code]
<xs:element name="car">
  <xs:simpleType>
    <xs:restriction base="xs:string">
      <xs:enumeration value="Audi"/>
      <xs:enumeration value="Golf"/>
      <xs:enumeration value="BMW"/>
    </xs:restriction>
  </xs:simpleType>
</xs:element>
\end{lstlisting}

Para limitar o conteúdo de um elemento XML, para definir uma série de números ou
letras que possam ser utilizadas, pode-se usar a restrição pattern. Abaixo,
vemos algumas das formas como pode ser usado o pattern.

\begin{lstlisting}[style = XML_source_code]
<!-- Só pode conter uma letra e minúscula-->
<xs:element name="letter">
  <xs:simpleType>
    <xs:restriction base="xs:string">
      <xs:pattern value="[a-z]"/>
    </xs:restriction>
  </xs:simpleType>
</xs:element>

<!-- Contém 3 letras maiúsculas-->
<xs:element name="initials">
  <xs:simpleType>
    <xs:restriction base="xs:string">
      <xs:pattern value="[A-Z][A-Z][A-Z]"/>
    </xs:restriction>
  </xs:simpleType>
</xs:element>

<!-- Contém 3 letras, seja maiúscula ou minuscule --> 
<xs:element name="initials">
  <xs:simpleType>
    <xs:restriction base="xs:string">
      <xs:pattern value="[a-zA-Z][a-zA-Z][a-zA-Z]"/>
    </xs:restriction>
  </xs:simpleType>
</xs:element>

<!-- Só aceita um dos tres valores (x, y ou Z)-->
<xs:element name="choice">
  <xs:simpleType>
    <xs:restriction base="xs:string">
      <xs:pattern value="[xyz]"/>
    </xs:restriction>
  </xs:simpleType>
</xs:element>

<!-- Aceita 5 dígitos de 0 a 9 -->
<xs:element name="prodid">
  <xs:simpleType>
    <xs:restriction base="xs:integer">
      <xs:pattern value="[0-9][0-9][0-9][0-9][0-9]"/>
    </xs:restriction>
  </xs:simpleType>
</xs:element>

<!-- Aceita zero ou mais ocorrencias de letras minúsculas de a – z -->
<xs:element name="letter">
  <xs:simpleType>
    <xs:restriction base="xs:string">
      <xs:pattern value="([a-z])*"/>
    </xs:restriction>
  </xs:simpleType>
</xs:element>
\end{lstlisting}

\subsection{Comlex Types}\label{Comlex Types}

Um tipo complexo é um elemento que contém outros elementos e/ou atributos.
Existem quatro tipos de elementos complexos:
\begin{itemize}
\item{Elementos vazios.}
\item{Elementos que contém outros elementos.}
\item{Elementos que contém apenas texto.}
\item{Elementos que contém tanto outros elementos quanto texto.}
\end{itemize}

Abaixo, temos um exemplo de um elemento XML complexo contendo apenas outros
elementos.

\begin{lstlisting}[style  =  XML_source_code]
<employee>
  <firstname>John</firstname>
  <lastname>Smith</lastname>
</employee>

\end{lstlisting}
 
OS elementos complexos podem ser definidos em um schema XML de duas maneiras:


1.	O elemento pode ser declarado diretamente pelo nome dele como podemos ver no
exemplo de empregado:

\begin{lstlisting}[style  =  XML_source_code]
<xs:element name="employee">
  <xs:complexType>
    <xs:sequence>
      <xs:element name="firstname" type="xs:string"/>
      <xs:element name="lastname" type="xs:string"/>
    </xs:sequence>
  </xs:complexType>
</xs:element>
\end{lstlisting}
 
Ao se utilizar o método descrito acima, apenas o elemento ``employee'' pode usar o
complex type especificado. Note que os elementos filhos,  "firstname" e
"lastname", estão cercados pela tag <sequence>, o que significa que devem
aperecer na ordem em que foram declarados. 
\\
\\
2.	O elemento pode ter um tipo de atributo que faz referência a um tipo complexo
para uso-lo:

\begin{lstlisting}[style  =  XML_source_code]
<xs:element name="employee" type="personinfo"/>

<xs:complexType name="personinfo">
  <xs:sequence>
    <xs:element name="firstname" type="xs:string"/>
    <xs:element name="lastname" type="xs:string"/>
  </xs:sequence>
</xs:complexType>

\end{lstlisting} 

Utilizando esse tipo de declaração, outros elementos poderão fazer referência ao
mesmo tipo complexo como podemos ver abaixo.

\begin{lstlisting}[style  =  XML_source_code]

<xs:element name="employee" type="personinfo"/>
<xs:element name="student" type="personinfo"/>
<xs:element name="member" type="personinfo"/>

<xs:complexType name="personinfo">
  <xs:sequence>
    <xs:element name="firstname" type="xs:string"/>
    <xs:element name="lastname" type="xs:string"/>
  </xs:sequence>
</xs:complexType>

\end{lstlisting}
 
Pode-se ainda basear um elemento complexo em outro já existente e adicionar
mais alguns elementos.

\begin{lstlisting}[style  =  XML_source_code]

<xs:element name="employee" type="fullpersoninfo"/>

<xs:complexType name="personinfo">
  <xs:sequence>
    <xs:element name="firstname" type="xs:string"/>
    <xs:element name="lastname" type="xs:string"/>
  </xs:sequence>
</xs:complexType>

<xs:complexType name="fullpersoninfo">
  <xs:complexContent>
    <xs:extension base="personinfo">
      <xs:sequence>
        <xs:element name="address" type="xs:string"/>
        <xs:element name="city" type="xs:string"/>
        <xs:element name="country" type="xs:string"/>
      </xs:sequence>
    </xs:extension>
  </xs:complexContent>
</xs:complexType>

\end{lstlisting}

 Além de elementos com apenas outros elementos como vimos nos primeiros
 exemplos, existem elementos com apenas texto como podemos ver abaixo:
 
 \begin{lstlisting}[style  =  XML_source_code]

<xs:element name="somename">
  <xs:complexType>
    <xs:simpleContent>
      <xs:extension base="basetype">
        ....
        ....
      </xs:extension>
    </xs:simpleContent>
  </xs:complexType>
</xs:element>

OR

<xs:element name="somename">
  <xs:complexType>
    <xs:simpleContent>
      <xs:restriction base="basetype">
        ....
        ....
      </xs:restriction>
    </xs:simpleContent>
  </xs:complexType>
</xs:element>

 \end{lstlisting}
 
Após adicionar o elemento <simpleContent> em volta do conteúdo, precisa-se
definir se é uma extensão ou uma restrição para se expandir ou limitar a base
do tipo simples para o elemento.



Existe ainda  o tipo complexo misto, que contém tanto texto como outros
elementos. O exemplo abaixo  demonstra um elemento XML misto e a declaração
dele. 

\begin{lstlisting} [style = XML_source_code] <letter>
  Dear Mr.<name>John Smith</name>.
  Your order <orderid>1032</orderid>
  will be shipped on <shipdate>2001-07-13</shipdate>.
</letter>
\end{lstlisting}

\begin{lstlisting} [style = XML_source_code]
<xs:element name="letter">
  <xs:complexType mixed="true">
    <xs:sequence>
      <xs:element name="name" type="xs:string"/>
      <xs:element name="orderid" type="xs:positiveInteger"/>
      <xs:element name="shipdate" type="xs:date"/>
    </xs:sequence>
  </xs:complexType>
</xs:element>
\end{lstlisting}

Os elementos podem ser controlados com indicadores sobre como eles serão usados
no documento. Existem sete indicadores divididos em três tipos:
\begin{itemize}
  \item Indicadores de Ordem: 
  \begin {itemize}
    \item All
    \item Choice
    \item Sequence
   \end{itemize}
   \item Indicadores de Ocorrência:
   \begin {itemize}
    \item maxOccurs
    \item minOccurs
   \end{itemize}
   \item Indicadores de Grupo:
   \begin {itemize}
    \item Group name
    \item attributeGroup name
   \end{itemize}
\end{itemize}

\subsubsection{Indicadores de Ordem}
Os indicadores de ordem, como o nome sugere, indicam a ordem em que um elemento
pode aparecer.


 O indicador <all> especifica que os elementos filhos podem aparecer em qualquer ordem e que cada elemento filho só pode ocorrer uma vez. 

\begin{lstlisting} [style = XML_source_code]
<xs:element name="person">
  <xs:complexType>
    <xs:all>
      <xs:element name="firstname" type="xs:string"/>
      <xs:element name="lastname" type="xs:string"/>
    </xs:all>
  </xs:complexType>
</xs:element>
\end{lstlisting}


O indicador <choice> especifica que tanto um elemento filho quanto o outro podem ocorrer.

\begin{lstlisting} [style = XML_source_code]
<xs:element name="person">
  <xs:complexType>
    <xs:choice>
      <xs:element name="employee" type="employee"/>
      <xs:element name="member" type="member"/>
    </xs:choice>
  </xs:complexType>
</xs:element>
\end{lstlisting}


Já o indicador <sequence> especifica que os elementos filhos devem aparecer em uma ordem específica.

\begin{lstlisting} [style = XML_source_code]
<xs:element name="person">
   <xs:complexType>
    <xs:sequence>
      <xs:element name="firstname" type="xs:string"/>
      <xs:element name="lastname" type="xs:string"/>
    </xs:sequence>
  </xs:complexType>
</xs:element>
\end{lstlisting}

\subsubsection{Indicadores de Ocorrência}

O indicadores de ocorrência são usados para definir com que frequência um
elemento pode ocorrer.

O indicador <maxOccurs> especifica o número máximo de vezes em que o elemento
pode ocorrer:

\begin{lstlisting}[style = xml_source_code]
<xs:element name="person">
  <xs:complexType>
    <xs:sequence>
      <xs:element name="full_name" type="xs:string"/>
      <xs:element name="child_name" type="xs:string" maxOccurs="10"/>
    </xs:sequence>
  </xs:complexType>
</xs:element>
\end{lstlisting}

O indicador <minOccurs> especifica o número mínimo de vezes que um elemento pode
ocorrer:

\begin{lstlisting}[style = xml_source_code]
<xs:element name="person">
  <xs:complexType>
    <xs:sequence>
      <xs:element name="full_name" type="xs:string"/>
      <xs:element name="child" type="xs:string"
      maxOccurs="10" minOccurs="0"/>
    </xs:sequence>
  </xs:complexType>
</xs:element>
\end{lstlisting}

O exemplo acima, indica que o elemento ``child'' pode ocorrer no mínimo zero
e no máximo dez vezes dentro do elemento ``person''.

\subsubsection{Indicadores de Grupo}

Indicadores de grupo são usados para definir conjuntos de elementos
relacionados. 

O elemento ``group'' é definido com uma declaração como a vista abaixo. É preciso
definir um indicador de ordem (all, choice, sequence) dentro da declaração do
grupo. O exemplo abaixo define um grupo chamado ``persongroup'', que define um
grupo de elementos que precisam ocorrer em uma sequência exata:

\begin{lstlisting}[style = xml_source_code]
<xs:group name="persongroup">
  <xs:sequence>
    <xs:element name="firstname" type="xs:string"/>
    <xs:element name="lastname" type="xs:string"/>
    <xs:element name="birthday" type="xs:date"/>
  </xs:sequence>
</xs:group>
\end{lstlisting}

Depois de se definir um grupo, pode-se fazer referencia a ele em outra
definição.

\begin{lstlisting}[style = xml_source_code]
<xs:group name="persongroup">
  <xs:sequence>
    <xs:element name="firstname" type="xs:string"/>
    <xs:element name="lastname" type="xs:string"/>
    <xs:element name="birthday" type="xs:date"/>
  </xs:sequence>
</xs:group>

<xs:element name="person" type="personinfo"/>

<xs:complexType name="personinfo">
  <xs:sequence>
    <xs:group ref="persongroup"/>
    <xs:element name="country" type="xs:string"/>
  </xs:sequence>
</xs:complexType>
\end{lstlisting}






\section{JavaScript}
JavaScript é a linguagem script mais popular da internet e funciona com  a
maioria dos navegadores, tal qual Internet Explorer, Firefox, Chrome, Opera e
Safari. O JavaScript foi desenhado para adicionar interatividade para as
páginas HTML e, por ser uma linguagem de programação mais ``leve'', é anexada
diretamente na página HTML. Outra vantagem do JavaScript é que, por ser uma
linguagem interpretada, não precisa ser compilada para executar.

O JavaScript pode ser usado para diversas funções no ambiente web, como por
exemplo: dar aos web designers uma ferramenta de programação com uma sintaxe
muito simples, o que permite a pessoas que não estão familiarizadas com as
linguagens de programação tradicionais colocarem uma certa inteligência em suas
páginas web. O JavaScript também é capaz de reagir a eventos, como por exemplo,
quando uma página terminar de carregar ou quando um usuário clicar em um
elemento HTML.  Outras funcionalidades são: validar dados, detectar o navegador
do usuário, criar cookies (salvar e manter informações no computador do
usuário), etc.

A tag HTML <script> é usada para inserir um Javascript em uma página HTML e
pode ser declarada tanto dentro do <head> quanto dentro do <body>, ou até mesmo
nos dois ao mesmo tempo. Outra alternativa para se usar um JavaScript é
utilizando um arquivo externo, como no caso de se querer executar o mesmo script
em várias páginas diferentes. Ao invés de se escrever o mesmo script em todas
elas, faz-se um arquivo (.js) e apenas declara em cada página que irá usar o
script.

Assim como outras linguagens de script, o JavaScript nada mais é do que uma
sequência de comandos a serem executados pelo navegador na ordem em que são
escritos. O JavaScript pode usar também o conceito de bloco para indicar que os
comandos pertencentes a ele devem ser executados em conjunto. Outros detalhes
da linguagem é que ela é case sensitive e possui a opção de comentar linhas de
código ou blocos inteiros.

Além de todas essas funcionalidades, o JavaScript é uma linguagem orientada a
objetos, o que permite que o programador crie seus próprios objetos e tipos.
Mais que isso, pode ser usada para uma série de funções como: validação de
dados, animações, mapeamento de imagens e eventos por tempo. O JavaScript também
pode ser usada em conjunto com o XML gerando uma nova forma de se utilizar
padrões existentes. Essa nova forma é denominada AJAX e será estudada mais a
fundo na próxima seção.




\section{AJAX - Asynchronous JavaScript and XML}
Ajax não é uma nova linguagem de programação, mas sim uma nova maneira de
utilização do que já existe. É considerada por alguns a arte de se trocar dados
com um servidor de forma assíncrona e atualizar partes da página web sem
recarregar a página inteira.

Na figura \ref{fig:Funcionamento-AJAX} segue um exemplo funcional do AJAX:

\begin{figure}[h]
    \centering
    \includegraphics[width=90mm]{figuras/Funcionamento-AJAX.png}
    \caption{Exemplo Funcional do AJAX}
    \label{fig:Funcionamento-AJAX}
 \end{figure}

Apesar de parecer que funciona como o antigo HTML, o AJAX possui um poder muito
maior, pois é capaz de permitir que o usuário continue trabalhando na página
web enquanto o servidor recebe algum tipo de requisição e a processa. Após
processar internamente a requisição feita, o servidor devolve uma mensagem ao
cliente e se esta envolver dados, os mesmos são transportados em XML. Ao chegar
no navegador do cliente, esta resposta é processada e interpretada pelo
JavaScript, que consegue dizer claramente o que aquele documento em XML
representa e o transforma em formato HTML para que o navegador possa
exibir o que for necessário.

\subsection{Criando um Objeto XMLHttpRequest}

Todos os navegadores modernos suportam o objeto XMLHttpRequest, com exceção ao
Internet Explorer 5 e ao Internet Explorer 6 que usam um ActiveXObject.

O objeto XMLHttpRequest é utilizado para a troca de dados com o servidor de
forma silenciosa. Ao utilizar um Web Service, por exemplo, o desenvolvedor da
pagina web faria uma chamada local a procedimentos e à funções que existissem
no servidor e enviaria a requisição XML empacotada pelo SOAP via HttpRequest no
formato esperado pelo servidor.

Abaixo, podemos ver a sintaxe para a criação de um objeto XMLHttpRequest
dependendo da versão do navegador utilizada pelo usuário.

\begin{lstlisting}[style = c_source_code]
getXmlHttp: function() { 
    try {
        if (window.XMLHttpRequest) {
            var req = new XMLHttpRequest();
            if (req.readyState == null) {
                req.readyState = 1;
                req.addEventListener("load", 
                                    function() {
                                    req.readyState = 4;
                                    if (typeof req.onreadystatechange == "function")
                                        req.onreadystatechange();
                                    },
                                    false);
            }
            return req;
        }
        if (window.ActiveXObject) {
            var parsers = ["Msxml2.XMLHTTP.5.0",
    	                   "Msxml2.XMLHTTP.4.0",
                           "MSXML2.XMLHTTP.3.0",
                           "MSXML2.XMLHTTP", 
                           "Microsoft.XMLHTTP"]; 
           for(var i = 0; i < parsers.length; i++) { 
               try {
                   return new ActiveXObject(parsers[i]);
               }
               catch (ex) {};
            }
            throw new Error("Impossível encontrar um Xml parser instalado");
        }
    }
    catch (ex) {}
	throw new Error("Este navegador não suporta objectos XmlHttp");
	}
\end{lstlisting}

Para enviar uma requisição ao servidor, deve-se utilizar os métodos open() e
send() do objeto XMLHttpRequest. 

\begin{lstlisting}[style = c_source_code]
xmlhttp.open("GET","ajax_info.txt",true);
xmlhttp.send();
\end{lstlisting}

Ao se construir uma requisição, deve-se informar o seu tipo, a url e se deverá
ser assíncrona ou não. O primeiro parâmetro pode ser do tipo GET ou POST, vamos
explicar a diferença entre eles mais adiante. A url deverá conter o local do
arquivo no servidor e para dizer que a requisição é assíncrona deve-se passar o
último parâmetro como ``true'', caso contrário, se for ``false'', a requisição
será considerada síncrona.

O método GET é mais simples e mais rápido que o método POST, e pode ser usado na
maioria dos casos. Entretanto, em alguns casos listados abaixo, deve-se sempre
utilizar o método POST.

\begin{itemize}
	\item{Arquivos em cache não são uma opção (atualizar um arquivo ou banco no
	servidor).}
	\item{Enviar uma grande quantidade de dados para o servidor (POST não tem
	limitações de tamanho.)}
	\item{Enviar uma entrada do usuário que possa conter caracteres
	desconhecidos. POST é mais robusto e seguro do que GET.}	
\end{itemize}

Para que se receba uma resposta do servidor, deve-se utilizar as propriedades
``responseText'' ou ``responseXML'' do objeto XMLHttpRequest. Como o nome mesmo já nos
induz a pensar, o ``responseText'' é usado quando a resposta esperada é um texto
simples e é passada como ``string''. Já o ``responseXML'' que é o nosso objeto de
estudo, é capaz de receber como resposta do servidor um XML, o que nos permite
fazer um parser desse XML para tratar e pegar a informação que estamos esperando.\\


\begin{lstlisting}[style = html_source_code]
<html>
<head>
<script type="text/javascript">
\end{lstlisting}
\begin{lstlisting}[style = js_source_code]
function loadXMLDoc()
{
  xmlhttp=new XMLHttpRequest();
  xmlhttp.onreadystatechange=function(){
  if (xmlhttp.readyState==4 && xmlhttp.status==200)
    {
    xmlDoc=xmlhttp.responseXML;
    var txt="";
    x=xmlDoc.getElementsByTagName("ARTIST");
    for (i=0;i<x.length;i++)
      {
      txt=txt + x[i].childNodes[0].nodeValue + "<br />";
      }
    document.getElementById("myDiv").innerHTML=txt;
    }
  }
xmlhttp.open("GET","cd_catalog.xml",true);
xmlhttp.send();
}
\end{lstlisting}
\begin{lstlisting}[style = html_source_code]
</script>
</head>

<body>

<h2>My CD Collection:</h2>
<div id="myDiv"></div>
<button type="button" onclick="loadXMLDoc()">Get my CD collection</button>
 
</body>
</html>

\end{lstlisting}

O exemplo acima, mostra uma página web que deseja receber o nome dos artistas da
coleção de cds do usuário. Após receber a resposta em XML, o script busca a tag
“ARTIST”, e para cada nó filho dessa tag atribui o valor desse nó, que seria o
nome do artista, à variável txt para depois exibir na página.\\


\begin{lstlisting}[style = xml_source_code]
xmlDoc=xmlhttp.responseXML;
    var txt="";
    x=xmlDoc.getElementsByTagName("ARTIST");
    for (i=0;i<x.length;i++)
      {
      txt=txt + x[i].childNodes[0].nodeValue + "<br />";
      }
    document.getElementById("myDiv").innerHTML=txt;
\end{lstlisting}



Para perceber que uma resposta do servidor está pronta, utilizamos o evento
``onreadystatechange'', que é disparado a cada mudança de estado da propriedade
``readyState''. A tabela \ref{tab:Objeto XMLHttlRequest} exemplifica como são tratadas as propriedades
do objeto ``XMLHttpRequest''.

\\
\\
\\
\\
\\
\\

\begin{table}[h]
	\centering
		\begin{tabular}{|l|l|}
		  \hline
		    Propriedade & Descrição \\ \hline
			onreadystatechange & Guardar uma função para ser chamada toda vez \\
			                   & que a propriedade readyState mudar. \\ \hline
		    readyState & Guarda o status do XMLHttpRequest.\\ 
		               & Variam entre 0 e 4:\\
		               & 0: Requisição não inicializada. \\
					   & 1: Conexão com o servidor estabilizada.\\
					   & 2: Requisição recebida.\\
					   & 3: Processando Requisição.\\ 
					   & 4: Requisição terminada e resposta está Pronta. \\ \hline
			Status     & 200: "OK". \\
				       & 404: Page not found. \\ \hline
		\end{tabular}
		\caption{Objeto XMLHttlRequest}
		\label{tab:Objeto XMLHttlRequest}
\end{table}

\section{Java}

Java é uma linguagem de programação orientada a objetos, altamente portável,
podendo ser utilizada em qualquer dispositivo independente da plataforma. Para
isso, basta que o dispositivo tenha uma máquina virtual Java (JVM) instalada.
Pois, diferentemente das linguagens convencionais, que são compiladas para uma
linguagem de máquina e por isso precisam levar em consideração o ambiente em
que vão executar, o Java é compilado em tempo de execução em cima da JVM, o que
permite que ele seja portável para qualquer ambiente, já que a JVM é que vai
executar o código.

Outro ponto forte do Java é a garantia na hora de manipular arquivos, seja
escrevendo ou lendo, de que conseguirá terminar a ação, o que permitiu com que
os stubs fossem gerados para JavaScript de forma confiável.

\chapter{Padrões utilizados}
\thispagestyle{empty} % retira numeracao da pagina, conforme as normas de apresentacao.

Existem atualmente duas versões do padrão WSDL para a descrição de Web Services,
segundo o consórcio W3C: a versão 1.1, recomendada pelo W3C em março de 2003 e a
mais recente, a versão 2.0 recomendada em junho de 2007.

Neste capítulo abordaremos as duas versões supracitadas de WSDL e o padrão SOAP
1.1 correlacionando os padrões utilizados para operacionalizar Web Services.

\section{WSDL 1.1}
Uma definição completa de WSDL contém toda a informação necessária para
realizar uma chamada a um Web Service. Um WSDL é um documento XML  com uma
definição de elemento raiz em \textit{http://schemas.xmlsoap.org/wsdl/}
namespace. O schema completo de um WSDL está disponivel em
\textit{http://schemas.xmlsoap.org/wsdl/}. A definição de um elemento pode
conter vários outros elementos, incluindo tipos, mensagens, PortTypes, binding e
serviços.

Na versão 1.1, o WSDL era composto basicamente de sete parâmetros:

\begin{itemize}
\item{\textbf{Types}: Um container para definição de tipos de dados usando
algum sistema de tipos como XSD.}
\item{\textbf{Message}: Uma definição abstrata dos tipo de dados que serão
usados durante a comunicação.}
\item{\textbf{Operation}: Uma definição abstrata de uma ação suportada pelo
serviço.}
\item{\textbf{PortType}: Um conjunto abstrato de operações suportadas por um ou
mais pontos de saída.}
\item{\textbf{Binding}: Definição concreta de um protocolo e da
especificação de um formato de dados para um PortType particular.}
\item{\textbf{Port}: Definição concreta de um único ponto de saída por meio da
combinação de binding e endereço de rede.}
\item{\textbf{Service}: Uma coleção de pontos de saída relacionados.}
\end{itemize}

É importante observar que o WSDL não introduz uma nova linguagem de definição
de tipos. O WSDL reconhece a necessidade por sistemas ricos de tipos para a
descrição de formato de mensagens, e suporta o XML Schemas specification (XSD)
como o padrão do sistema. O WSDL cobre o que XML
Schema não consegue, provendo um meio de agrupar as mensagens em operações e as
operações em interfaces. Ainda provém uma maneira de definir Bindings  para cada interface e
combinações de protocolos com pontos de saída.
	
O esquema da figura \ref{fig:abstract-definitions} mostra como estes sete parâmetros se relacionam
entre si. As setas com um ponto representam um relacionamento do tipo ``refere-se à'' ou ainda
``utiliza''. A seta dupla indica um modificador e a seta em três dimensões indica
um relacionamento do tipo ``Contém''. Assim, Messages usa Types e é usado por
PortTypes. PortType e Binding contêm Operations e o Operations do PortType é
modificado pela Operations do Binding.

Types, Messages e PortTypes são definições abstratas enquanto Bindings Services
e Ports são definições concretas. Apenas Operation pode ser tanto uma definição
abstrata quanto uma definição Concreta. 

  \begin{figure}[h]
    \centering
    \includegraphics[width=90mm]{figuras/abstract-definitions.png}
    \caption{Abstract Definitions}
    \label{fig:abstract-definitions}
  \end{figure}

\subsection{Exemplo do WSDL 1.1}
O exemplo abaixo ilustra a estrutura básica de uma definição de WSDL:

\begin{lstlisting}[style=xml_source_code] 
<!-- WSDL definition structure -->
<definitions
    name="MathService"
    targetNamespace="http://example.org/math/"
    xmlns=http://schemas.xmlsoap.org/wsdl/
>

<!-- abstract definitions -->
    <types> ...
    <message> ...
    <portType> ...

<!-- concrete definitions -->
    <binding> ...
    <service> ...

</definition> 
\end{lstlisting}

Note que é necessário especificar um namespace destino para a definição de um
WSDL, assim como seria feito para a definição de um XML schema. Qualquer
parâmetro seja nomeada na definição de um WSDL (como message, portType, etc)
automaticamente se tornará parte das definições do namespace destino definidos
pelo atributo targetNamespace.

\subsubsection{Types}
O elemento Types do WSDL é um container para definições de tipo XML schema. As
definições de tipo inseridas nesse elemento são referenciadas no nível mais
alto das definições da mensagem para definir os detalhes estruturais da mesma.
	
O elemento Types contém zero ou mais schemas do namespace
\textit{http://www.w3.org/2001/XMLSchema}.
	
Segue abaixo a estrutura básica do elemento Types:

\begin{lstlisting}[style=xml_source_code] 
<definitions .... >
    <types>
        <xsd:schema .... />*
    </types>
</definitions>
\end{lstlisting}

\subsubsection{Messages}
O elemento ``message'' do WSDL define uma mensagem abstrata que tanto pode servir
como entrada ou como saída de uma operação. O elemento ``message'' consiste em um
ou mais elementos Part no qual cada Part é associado tanto a um Elemento, quando
utiliza um estilo Document, quanto a um Type, quando utiliza um estilo RPC.
Segue abaixo a estrutura básica de uma definição de mensagem:

\begin{lstlisting}[style=xml_source_code] 
<definitions ...>
    <message name=" .. " ... >
        <part name=" .. " ... >
    </message>
</definitions>
\end{lstlisting}

As mensagens e as partes precisam ser nomeadas para que possam ser referenciadas
em qualquer lugar da definição do WSDL. Quando define-se um serviço estilo RPC,
as partes da mensagem representam parâmetros de métodos. Neste caso, o name das
partes torna-se o name de um elemento na mensagem concreta e esta estrutura é
determinada pelo tipo do atributo fornecido. Quando define-se  um serviço
estilo document as partes referem-se a elementos XML inseridos no body.

\subsubsection{Interfaces (portTypes)}
O elemento portType do WSDL define um grupo de operações, também conhecida como
interface na maioria dos ambientes. Um elemento PortType contém zero ou mais
operações. A estrutura básica do portType pode ser vista abaixo:

\begin{lstlisting}[style=xml_source_code] 
<definitions .... >
	   <portType name="nmtoken">
		<operation name="nmtoken" .... /> *
	   </portType>
</definitions>
\end{lstlisting}

Cada portType deve receber um nome único para que possa ser referenciado de
qualquer parte da definição do WSDL. Cada operação contém uma combinação de
elementos de entrada e saída, e quando se há um elemento de saída pode-se ter
ainda um elemento de falha. A ordem desses elementos define o padrão da troca
de mensagens (MEP) suportada pela dada operação.

Por exemplo, um elemento de entrada seguido por um elemento de saída define uma
operação de ``request-response'', enquanto um elemento de saída seguido por um
de entrada define uma operação de ``solicit-response''. Uma operação que contém
apenas o elemento de entrada define-se como uma one-way, enquanto a que contém
apenas o elemento saída define-se como uma operação de notificação.

\subsubsection{Bindings}
O elemento Binding do WSDL descreve de forma concreta os detalhes do uso de um
portType com um determinado protocolo. O elemento Binding contém vários
elementos de extensibilidade bem como um elemento de operação do WSDL para cada
operação descrita no portType. Segue abaixo a estrutura básica do elemento
Binding.

\begin{lstlisting}[style=xml_source_code] 
<wsdl:definitions .... >
    <wsdl:binding name="nmtoken" type="qname"> *
   
        <-- extensibility element providing binding details --> *
        <wsdl:operation name="nmtoken"> *

            <-- extensibility element for operation details --> *
            <wsdl:input name="nmtoken"? > ?
                <-- extensibility element for body details -->
            </wsdl:input>

            <wsdl:output name="nmtoken"? > ?
                <-- extensibility element for body details -->
            </wsdl:output>
	      
            <wsdl:fault name="nmtoken"> *
                <-- extensibility element for body details -->
            </wsdl:fault>
	   
	   </wsdl:operation>
	</wsdl:binding>
</wsdl:definitions>
\end{lstlisting}

O Binding deve ter um nome único para que possa ser consultado em outra parte na
definição WSDL. Os Bindings ainda precisam especificar qual portType estão
descrevendo através do atributo Type. Atualmente, os detalhes de um binding são
providos utilizando elementos de extensibilidade. Esta arquitetura permite o
WSDL evoluir ao longo do tempo, uma vez que qualquer elemento pode ser usado nos
slots pré-definidos. A especificação WSDL disponibiliza alguns elementos
bindings para descrever SOAP bindings, apesar de eles estarem em um namespace
diferente. O exemplo a seguir mostra um binding SOAP/HTTP para o portType MathInterface:

\begin{lstlisting}[style=xml_source_code] 
<definitions
  xmlns="http://schemas.xmlsoap.org/wsdl/"
  xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
  xmlns:xs="http://www.w3.org/2001/XMLSchema"
  xmlns:y="http://example.org/math/"
  xmlns:ns="http://example.org/math/types/"
  targetNamespace="http://example.org/math/">
...

    <binding name="MathSoapHttpBinding" type="y:MathInterface">
        <soap:binding style="document"
          transport="http://schemas.xmlsoap.org/soap/http"/>
            <operation name="Add">
                <soap:operation
                  soapAction="http://example.org/math/#Add"/>
                    <input>
                        <soap:body use="literal"/>
                    </input>
                    <output>
                        <soap:body use="literal"/>
                    </output>
            </operation>
...
    </binding>
...
</definitions>
\end{lstlisting}

O elemento soap:binding indica que esse é  binding SOAP 1.1, ele ainda indica o
estilo padrão do serviço junto com protocolo de transporte necessário. O
elemento soap:operation define o valor do cabeçalho HTTPSOAPAction para cada
operação e o elemento soap:body define como as partes da mensagem vão aparecer
dentro do elemento body do SOAP.

Usar o estilo document no SOAP, indica que o body conterá um documento XML e
que as partes da mensagem irão especificar o elemento XML que será colocado
no body. Usar o estilo RPC no SOAP indica que o body conterá uma representação
XML de uma chamada de método e as partes da mensagem representarão os parâmetros para
esse método.

O atributo ``uses'' especifica a codificação que deverá ser usada para traduzir as
partes de uma mensagem abstrata em uma representação concreta.

A combinação mais comum dos atributos SOAP style/use é document/literal, pois é
o que tem menos problemas de interoperabilidade.

\subsubsection{Services}
O elemento service do WSDL define uma coleção de ports ou endpoints, que expõe
um binding particular. Segue abaixo a estrutura básica do elemento service.

\begin{lstlisting}[style=xml_source_code] 
<definitions .... >
    <service .... > *
        <port name="nmtoken" binding="qname"> *
            <-- extensibility element defines address details -->
        </port>
    </service>
</definitions>
\end{lstlisting}

Deve-se dar a cada porta um nome e associá-la a um binding. Então, dentro do
elemento porta pode-se usar um elemento de extensibilidade para definir os
detalhes específicos do endereço de um binding. O exemplo a seguir define um
serviço MathService, que expõe o MathSoapHttpBinding na URL
\textit{http://localhost/math/math.asmx.}

\begin{lstlisting}[style=xml_source_code]
<definitions
  xmlns="http://schemas.xmlsoap.org/wsdl/"
  xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
  xmlns:xs="http://www.w3.org/2001/XMLSchema"
  xmlns:y="http://example.org/math/"
  xmlns:ns="http://example.org/math/types/"
  targetNamespace="http://example.org/math/"
>
    ...
    <service name="MathService">
        <port name="MathEndpoint" binding="y:MathSoapHttpBinding">
            <soap:address
              location="http://localhost/math/math.asmx"/>
       </port>
    </service>
</definitions>
\end{lstlisting}

\section{WSDL 2.0}
O Web Services Description Language na Versão 2.0 (WSDL 2.0) provê um modelo e
um formato XML para descrever Web Services. O WSDL 2.0 permite separar a descrição
das funcionalidades abstratas oferecidas por um serviço dos detalhes concretos
da descrição de um serviço, tal qual “como” e “onde” essa funcionalidade é
oferecida. O WSDL 2.0 descreve um Web Service em dois estágios fundamentais,
em que cada estágio, a descrição utiliza um número de construções para
promover a reutilização da descrição e para separá-la, independentemente de
preocupações de desing. No nível abstrato, o WSDL 2.0 descreve um Web Service
em termos de mensagens que envia e recebe.

Uma operação associa um padrão de troca de mensagem com uma ou mais mensagens.
O padrão de troca de mensagens identifica a sequência e a cardinalidade das
mensagens enviadas e/ou recebidas bem como a quem ela está sendo logicamente
enviada e/ou de quem é recebida. Uma interface agrupa operações sem qualquer
compromisso com o transporte.

No nível concreto, o binding especifica o transporte e os detalhes do formato de
wire para uma ou mais interfaces. Um endpoint associa um endereço de rede com
um binding. Finalmente, um serviço agrupa endpoints que implementam uma
interface em comum. 

\subsection{Descrição}

  \begin{figure}[h]
    \centering
    \includegraphics[width=130mm]{figuras/description-visao-geral.png}
    \caption{Description - Visão geral}
    \label{fig:description-visao-geral}
  \end{figure}
  
Como pode ser visto na figura \ref{fig:description-visao-geral}, o componente o
Description é apenas um container para dois tipos de componentes de alto nível:

\begin{itemize}
  \item{Componentes WSDL (Interface, Binding, Service)}
  \item{Componentes sistemas de tipo (Element declarations, type definitions)}
\end{itemize}

Abaixo vemos uma representação XML do componente description:

\begin{lstlisting}[style=xml_source_code]
<xml version="1.0" encoding="utf-8" ?> 
<description
    targetNamespace=...
    xmlns=http://www.w3.org/2006/01/wsdl...>
    <types>
        <xs:schema...
            <xs:elementname=...>
            <xs:complexTypename=...>
        </xs:schema> 
    </types>
<interface> ... </interface>
<binding> ... </binding>
<service> ... </service>
</description>
\end{lstlisting}

O componente sistemas de tipo descreve as restrições do conteúdo da mensagem.
Por padrão, essas restrições são expressas em termos de [XML Information Set],
isto é. elas definem as propriedades de um elemento item de informação.

  \begin{figure}[h]
    \centering
    \includegraphics[width=60mm]{figuras/description-componente-system.png}
    \caption{Description - Componente System}
    \label{fig:description-componente-system}
  \end{figure}
  
É um invólucro abstrato para algum sistema subjacente, como próprio XML schema
ou outros sistemas de tipos como o RelaxNG baseado em XML ou o DTD que não
utiliza XML.

O Elemento Declaration é um schema global da declaração do elemento enquanto o
TypeDefinition  é um schema global da definição de tipos. Abaixo, temos uma
representação XML do componente sistema de tipo:

\begin{lstlisting}[style=xml_source_code]
<?xml version="1.0" encoding="utf-8" ?> 
<description 
  xmlns="http://www.w3.org/2006/01/wsdl"
  targetNamespace= . . . >
    <types>
        <xs:schema
          xmlns:xs="http://www.w3.org/2001/XMLSchema"
          targetNamespace="http://greath.example.com/2004/schemas/resSvc"
          xmlns="http://greath.example.com/2004/schemas/resSvc">

            <xs:element name="checkAvailability" type="tCheckAvailability"/> 
            <xs:complexType name="tCheckAvailability"> 
                <xs:sequence> 
                    <xs:element name="checkInDate" type="xs:date"/> 
                    <xs:element name="checkOutDate" type="xs:date"/> 
                    <xs:element name="roomType" type="xs:string"/> 
                </xs:equence> 
            </xs:complexType> 
            <xs:element name="checkAvailabilityResponse" type="xs:double"/> 
            <xs:element name="invalidDataError" type="xs:string"/> 
        </xs:schema> 
    </types>
...
</description>
\end{lstlisting}

Os componentes Interface, Binding, Service, Element Declaration e Type
Definition estão diretamente contidos no componente Description e são
referenciados como componentes de alto nível. Os componentes de alto nível do
WSDL 2.0 contêm outros componentes, por exemplo: Interface Operation e EndPoint,
que são referenciados como componentes aninhados. Componentes aninhados podem
conter outros componentes aninhados. O componente que contém um componente
aninhado é referenciado como pai desse componente. Os Componentes
aninhados têm uma propriedade pai que é uma referência a seus componentes pai.

As propriedades de um componente de Descrição estão expostas a seguir:

\begin{itemize}
  \item{Interfaces (opcional) – Conjunto de componentes Interface.}
  \item{Bindings (opcional) – Conjunto de componentes Binding.}
  \item{Services (opcional) – Conjunto de componentes Service.}
  \item{Element Declarations (opcional) – Conjunto de componentes Element
  Declaration.}
  \item{Type Definitions (requerido) – Conjunto de componentes Type Definition.} 
\end{itemize}

Na figura \ref{fig:description-componentes} temos um modelo dos componentes aninhados: 

  \begin{figure}[h]
    \centering
    \includegraphics[width=130mm]{figuras/description-componentes.png}
    \caption{Description - Componentes}
    \label{fig:description-componentes}
  \end{figure}

Note que eles vêm sempre abaixo de um dos componentes de alto nível (Interface,
Binding, Service) e que podem conter outros componentes aninhados.

\subsection{Componente Interface}
Um componente interface descreve sequências de mensagens que um serviço envia
e/ou recebe. Ele agrupa dentro de Operations, mensagens relacionadas. Um
Operation é uma sequência de mensagens de entrada e saída e interface é um
conjunto de Operations. Uma interface pode opcionalmente estender uma ou mais
interfaces. Para evitar definições recursivas, uma interface não pode aparecer
no conjunto de interfaces que ela estende, tanto diretamente quanto
indiretamente. O conjunto de operações disponíveis em uma interface inclui
todas as operações definidas por interfaces que ela estende direta ou
indiretamente. As operações definidas diretamente em uma interface são
referenciadas como operations da interface “declaradas”.

Na figura \ref{fig:interface-visao-geral} vemos um modelo do componente interface e de alguns
componentes aninhados a ela e a representação XML schema demonstrando os componentes em
destaque no modelo.

  \begin{figure}[h]
    \centering
    \includegraphics[width=75mm]{figuras/interface-visao-geral.png}
    \caption{Interface - Visão Geral}
    \label{fig:interface-visao-geral}
  \end{figure}
  
\begin{lstlisting}[style=xml_source_code]
<?xml version="1.0" encoding="utf-8" ?> 
<description targetNamespace=...
  xmlns="http://www.w3.org/2006/01/wsd" ...>
    <types> 
        <xs:schema...>
            <xs:elementname="invalidDataError" .../>
            <xs:elementname="checkAvailability" .../>
            ...
        </xs:schema>
    </types>
    <interface name = "reservationInterface" 
      extends=... styleDefault=...>
        <fault name = "invalidDataFault" 
          element = "ghns:invalidDataError"/>
        <operation name="opCheckAvailability"
          pattern=”http://www.w3.org/2006/01/wsdl/in-out”
          style="http://www.w3.org/2006/01/wsdl/style/iri">
            <input messageLabel="In" 
              element="ghns:checkAvailability" />
            <output messageLabel="Out"
              element="ghns:checkAvailabilityResponse" />
            <infault ref="tns:invalidDataFault" messageLabel=“In”/>
            <outfault ref="tns:invalidDataFault" messageLabel="Out"/>
        </operation>
    </interface>
...
</description>
\end{lstlisting}

\subsection{Componente Binding}
Um componente Binding descreve um formato de mensagem concreto e um protocolo de
transmissão que podem ser usados pra definir um endpoint, isto é, um componente
binding define os detalhes necessários para acessar um serviço.

Os componentes Binding podem ser usados para descrever tais informações em um
modo reutilizável para qualquer interface ou especificamente para uma dada
interface. Além disso, a informação do binding pode ser especificada em uma
base por informação dentro de uma interface, além de todas as operações em uma
interface.

Se um componente Binding especifica qualquer detalhe de operações específicas
de binding (incluindo componente Binding Operation) ou qualquer detalhe de
fault binding (incluindo componente Binding Fault), então ele deverá
especificar uma interface em que o componente binding foi aplicado, assim como
indicar de que interface a operação veio.

Reciprocamente, um componente binding que omite qualquer detalhe de operação
específica de binding e qualquer detalhe de fault binding pode omitir
especificando uma interface. Os componentes Binding que não especificam uma
interface podem ser usados para especificar detalhes de operações independentes
de binding para o componente Service com diferentes interfaces, isto é, tais
componentes Binding são reutilizáveis em uma ou mais interfaces.

Um componente Binding que define bindings para um componente Interface precisa
definir bindings para todas as operações de um componente Interface.

Na figura \ref{fig:binding-visao-geral} vemos um modelo do componente Binding e de alguns
componentes aninhados a ele e a representação XML schema demonstrando os componentes em destaque no
modelo.

  \begin{figure}[h]
    \centering
    \includegraphics[width=90mm]{figuras/binding-visao-geral.png}
    \caption{Binding - Visão Geral}
    \label{fig:binding-visao-geral}
  \end{figure}
  
\begin{lstlisting}[style=xml_source_code]
<?xml version="1.0" encoding="utf-8" ?> 
<description targetNamespace= ...
  xmlns="http://www.w3.org/2006/01/wsdl“ ...> 
    <types> ... </types>
    <interface name = "reservationInterface" > ... </interface>
    <binding name="reservationSOAPBinding"
      interface="tns:reservationInterface"
      type=http://www.w3.org/2006/01/wsdl/soap...">

        <fault ref="tns:invalidDataFault" 
          wsoap:code="soap:Sender"/>

        <operation ref="tns:opCheckAvailability" ...>
            <input>…</input>
            <output>….</output>
            <infault> …. </infault>
            <outfault> …. </outfault>
        </operation>
    </binding>
...
</description>
\end{lstlisting}

\subsection{Componente Service}
Um componente Service descreve um conjunto de endpoints em que uma implantação
de uma implementação particular do serviço é provida. Os endpoints, portanto,
são de fato lugares alternativos em que o serviço é prestado.

Na figura \ref{fig:service-visao-geral}, vemos um modelo do componente Service com o componente
endpoint aninhado a ele e a representação XML schema demonstrando os componentes em destaque no
modelo.

  \begin{figure}[h]
    \centering
    \includegraphics[width=40mm]{figuras/service-visao-geral.png}
    \caption{Service - Visão Geral}
    \label{fig:service-visao-geral}
  \end{figure}
  
\begin{lstlisting}[style=xml_source_code]
<?xml version="1.0" encoding="utf-8" ?> 
<description targetNamespace=...
  xmlns="http://www.w3.org/2006/01/wsdl“ ...>

    <types>...</types>
    <interface name="reservationInterface" > 
        ... 
    </interface>

    <binding name="reservationSOAPBinding"
      interface="tns:reservationInterface"... >
    ...
    </binding>

    <service name="reservationService"
      interface="tns:reservationInterface">
        <endpoint name="reservationEndpoint"
          binding="tns:reservationSOAPBinding"
          address="http://greath.example.com/2004/reservation"/>
    </service>
</description>
\end{lstlisting}

\section{Diferenças entre WSDL 1.1 e WSDL 2.0}
A grande maioria de WebServices que encontramos estava escrita em WSDL versão
1.1. A primeira dificuldade apareceu quando nos deparamos com a nova versão
2.0, que apesar de ainda não ter sido massificada, já é de utilização
recomendada pela W3C desde 2007. Como as duas versões apresentam diferenças
significativas, ficamos em dúvida se deveríamos dividir nossas atenções para as
duas ou se nos concentrávamos em uma delas. Por um lado, a versão 1.1 é ainda
amplamente utilizada, enquanto a versão 2.0 nos parece ser mais enxuta, com as
informações mais bem distribuídas no arquivo.

Durante os estudos, descobrimos que poderíamos adaptar qualquer arquivo WSDL
1.1 para os novos padrões do 2.0 através da api wodem apache. A seguir veremos
as principais diferenças entre as duas versões de WSDL.

\subsection{Comparação entre WSDL 1.1 e WSDL 2.0}
Como podemos ver na tabela \ref{tab:WSDL1.1 e WSDL2.0}, a grande diferença entre o WSDL 1.1 e o WSDL
2.0 é que o componente message passou a ser definido dentro do componente
operation.

  \begin{table}[h]
	\centering
		\begin{tabular}{|c|c|}
		  \hline
			WSDL 1.1 & WSDL 2.0 			\\ \hline
			<definitions> & <description> 	\\ \hline
			<portType> & <interface> 		\\ \hline
			<binding> & <binding> 			\\ \hline
			<types> & <types> 				\\ \hline
			<service> & <service> 			\\ \hline
			<port> & <endpoint> 			\\ \hline
			<message> & <operation> 		\\ \hline
		\end{tabular}
		\caption{WSDL1.1 e WSDL2.0}
		\label{tab:WSDL1.1 e WSDL2.0}
\end{table}

Outras alterações menos significativas do ponto de vista funcional são as
mudanças de nome. O componente definition passou a se chamar description, o
portType passou a se chamar interface e o port a se chamar endpoint. Na figura
\ref{fig:comparativo-wsdl11-wsdl20}, temos um esquema com uma correlação direta
entre cada componente.

  \begin{figure}[h]
    \centering
    \includegraphics[width=90mm]{figuras/comparativo-wsdl11-wsdl20.png}
    \caption{Comparativo - WSDL1.1 x WSDL2.0}
    \label{fig:comparativo-wsdl11-wsdl20}
  \end{figure}

Alguns pontos relevantes entre as diferenças são:

\begin{itemize}
  \item{\textbf{Sobrecarga de operações} -- O WSDL 1.1 utiliza os nomes dos
  elementos operation, input e output, enquanto no WSDL 2.0 só precisa ser
  nomeado pelo componente interface.}
  \item{\textbf{targetNamesapece} –- No WSDL 1.1, é opcional, enquanto no WSDL
  2.0 é obrigatório.}
  \item{\textbf{Definição do serviço} –- No WSDL 1.1, os componentes Services
  podem ter múltiplos componentes ports e cada port pode ser associado a um
  diferente portType. No WSDL 2.0, cada componente Service está associado a
  apenas um componente interface.}
  \item{\textbf{Ordem dos elementos de alto nível} -– No WSDL 1.1, os filhos de
  definition podem aparecer em qualquer ordem, enquanto no WSDL 2.0 a ordem é
  estritamente definida.}
  \item{\textbf{Definição de faults} –- Escopo no componente Operation no WSDL
  1.1 e no componente Interface no WSDL 2.0.}
  \item{\textbf{Importações} –- No WSDL 1.1, o componente Import importa o
  mesmo ou um targetNamespace diferente. Já o WSDL 2.0 utiliza Include para o mesmo
  targetNamespace e import para diferentes targetNamespace consistentes com o
  schema XML.}
\end{itemize}

\section{SOAP}
SOAP, originalmente, significava “Simple Object Access Protocol” e inicialmente
funcionava como um protocolo de acesso a objetos, mas com o passar do tempo,
tornou-se desejável que o SOAP servisse para um público muito mais amplo.
Portanto, o foco da especificação em objetos moveu-se rapidamente para um
framework de mensagens XML generalizadas. Hoje em dia, as definições 
encontradas nas especificações não mencionam mais objetos. O SOAP é um protocolo
leve para troca de informação estruturada em um ambiente distribuído
descentralizado. O SOAP usa a tecnologia XML para definir um extenso framework
de mensagens, que provêm uma construção de mensagens capaz de se comunicar por
meio da grande variedade de protocolos. O framework foi desenhado para ser
independente de qualquer modelo particular de programa e implementações com
semânticas específicas. O SOAP define um meio de mover mensagens XML de um ponto
A para um ponto B, como vemos na figura \ref{fig:troca-simples-de-uma-mensagem-soap}.

  \begin{figure}[h]
    \centering
    \includegraphics[width=90mm]{figuras/troca-simples-de-uma-mensagem-soap.png}
    \caption{Troca simples de uma mensagem SOAP}
    \label{fig:troca-simples-de-uma-mensagem-soap}
  \end{figure}

O SOAP pode ser usado sobre qualquer protocolo de transporte, tal qual TCP,
HTTP, SMPT, etc. Para manter a interoperabilidade, um protocolo padrão de
bindings precisa ser definido para delinear as regras de cada ambiente. A especificação
SOAP provém um framework flexível para definir arbitrariamente ligações dos
protocolos e provém um binding específico para o HTTP.

O SOAP permite qualquer modelo de programação e não é vinculado ao RPC, além de
definir um modelo para processamento individual e mensagens one-way.
Pode-se, porém, combinar múltiplas mensagens em uma troca de mensagens em geral.
A figura \ref{fig:troca-simples-de-uma-mensagem-soap} ilustra uma mensagem simples (one-way), na qual o
remetente não recebe uma resposta. O receptor pode, porém, enviar uma resposta de volta para o
remetente, como vemos na figura \ref{fig:padrao-request-response-de-troca-de-mensagens.png}.

  \begin{figure}[h]
    \centering
    \includegraphics[width=90mm]{figuras/padrao-request-response-de-troca-de-mensagens.png}
    \caption{Padrão Request/Response de troca de mensagens}
    \label{fig:padrao-request-response-de-troca-de-mensagens.png}
  \end{figure}
  
O SOAP permite qualquer número de padrão de troca de mensagem (MEPs), no qual
request/response é apenas um. Outros exemplos são: solicit/response (inverso de
request/response), notificações e longas conversações peer-to-peer.

\subsection{Framework de Mensagens}
A principal seção da especificação SOAP é o framework de mensagens. O
framework de mensagens SOAP define uma suíte de elementos XML para “empacotar”
arbitrariamente mensagens XML para transportar entre sistemas.

O framework é composto principalmente dos seguintes elementos XML:
Envelope, Header, Body e Fault. Todos estão no http://schemas.xmlsoap.org/soap/envelope/
namespace no SOAP 1.1. Segue abaixo a definição completa do schema XML do SOAP
1.1.

\begin{lstlisting}[style=xml_source_code]
<?xml version="1.0" encoding="utf-8" ?> 
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
  xmlns:tns="http://schemas.xmlsoap.org/soap/envelope/"
  targetNamespace="http://schemas.xmlsoap.org/soap/envelope/">

<!-- Envelope, header and body -->
    <xs:element name="Envelope" type="tns:Envelope" />
    <xs:complexType name="Envelope" >
        <xs:sequence>
            <xs:element ref="tns:Header" minOccurs="0" />
            <xs:element ref="tns:Body" minOccurs="1" />
            <xs:any namespace="##other" minOccurs="0"
              maxOccurs="unbounded" processContents="lax" />
        </xs:sequence>
        <xs:anyAttribute namespace="##other" 
          processContents="lax" />
    </xs:complexType>
    <xs:element name="Header" type="tns:Header" />
    <xs:complexType name="Header" >
        <xs:sequence>
            <xs:any namespace="##other" minOccurs="0"
              maxOccurs="unbounded" processContents="lax" />
        </xs:sequence>
    <xs:anyAttribute namespace="##other"
      processContents="lax" />
    </xs:complexType>
    <xs:element name="Body" type="tns:Body" />
    <xs:complexType name="Body" >
        <xs:sequence>
            <xs:any namespace="##any" minOccurs="0"
              maxOccurs="unbounded" processContents="lax" />
        </xs:sequence>
        <xs:anyAttribute namespace="##any"
          processContents="lax" />
    </xs:complexType>

<!-- Global Attributes -->
    <xs:attribute name="mustUnderstand" default="0" >
        <xs:simpleType>
            <xs:restriction base='xs:boolean'>
                <xs:pattern value='0|1' />
            </xs:restriction>
        </xs:simpleType>
    </xs:attribute>
    <xs:attribute name="actor" type="xs:anyURI" />
    <xs:simpleType name="encodingStyle" >
        <xs:list itemType="xs:anyURI" />
    </xs:simpleType>
    <xs:attribute name="encodingStyle"
      type="tns:encodingStyle" />
    <xs:attributeGroup name="encodingStyle" >
        <xs:attribute ref="tns:encodingStyle" />
    </xs:attributeGroup>
    <xs:element name="Fault" type="tns:Fault" />
    <xs:complexType name="Fault" final="extension" >
        <xs:sequence>
            <xs:element name="faultcode" type="xs:QName" />
            <xs:element name="faultstring" type="xs:string" />
            <xs:element name="faultactor" type="xs:anyURI"
              minOccurs="0" />
            <xs:element name="detail" type="tns:detail"
              minOccurs="0" />
        </xs:sequence>
    </xs:complexType>
    <xs:complexType name="detail">
        <xs:sequence>
            <xs:any namespace="##any" minOccurs="0"
              maxOccurs="unbounded" processContents="lax" />
        </xs:sequence>
        <xs:anyAttribute namespace="##any"
          processContents="lax" />
    </xs:complexType>
</xs:schema>
\end{lstlisting}

Observando a definição complexType para Envelope, pode-se perceber como esses
elementos comunicam-se entre si. O modelo de mensagem a seguir ilustra a
estrutura de um envelope SOAP.

\begin{lstlisting}[style=xml_source_code]
<soap:Envelope
  xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
    <soap:Header> <!-- optional -->
        <!-- header blocks go here... -->
    </soap:Header>
    <soap:Body>
        <!-- payload or Fault element goes here... -->
    </soap:Body>
</soap:Envelope>
\end{lstlisting}

O elemento Envelope é sempre o elemento raiz da mensagem SOAP. Isso facilita
a identificação ads mensagens SOAP olhando simplesmente para o nome do elemento
raiz.

O elemento Envelope contem um elemento opcional Header seguido de um elemento
obrigatório Body. O elemento Body representa a mensagem real, é um container
genérico que pode conter qualquer número de elementos de qualquer namespace.

O exemplo a seguir representa uma mensagem SOAP de requisição. 

\begin{lstlisting}[style=xml_source_code]
<soap:Envelope
  xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
    <soap:Body>
        <x:TransferFunds xmlns:x="urn:examples-org:banking">
            <from>22-342439</from>
            <to>98-283843</to>
            <amount>100.00</amount>
        </x:TransferFunds>
    </soap:Body>
</soap:Envelope>
\end{lstlisting}

Se o receptor suportar um request/response e estiver apto a processar a mensagem
com sucesso, deveria enviar uma outra mensagem SOAP de volta para o remetente
inicial. Neste caso, a resposta deveria também vir contida no elemento Body,
como mostra o código abaixo:

\begin{lstlisting}[style=xml_source_code]
<soap:Envelope
  xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
    <soap:Body>
        <x:TransferFundsResponse
          xmlns:x="urn:examples-org:banking">
            <balances>
                <account>
                    <id>22-342439</id>
                    <balance>33.45</balance>
                </account>
                <account>
                    <id>98-283843</id>
                    <balance>932.73</balance>
                </account>
            </balances>
        </x:TransferFundsResponse>
    </soap:Body>
</soap:Envelope>
\end{lstlisting}

O framework de mensagem também define um elemento chamado Fault para
representar erros dentro do elemento Body quando algo sai errado. Isso é
essencial, porque sem uma representação de erro padrão, toda aplicação teria
que inventar a sua própria, fazendo com que seja impossível para uma infra
estrutura genérica, distinguir entre sucesso e falha.

O exemplo a seguir contém o elemento Fault indicando um erro de “Insufficient
Funds” durante o processamento da requisição.

\begin{lstlisting}[style=xml_source_code]
<soap:Envelope
  xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
    <soap:Body>
        <soap:Fault>
            <faultcode>soap:Server</faultcode>
            <faultstring>Insufficient funds</faultstring>
            <detail>
                <x:TransferError xmlns:x="urn:examples-org:banking">
                    <sourceAccount>22-342439</sourceAccount>
                    <transferAmount>100.00</transferAmount>
                    <currentBalance>89.23</currentBalance>
                </x:TransferError>
            </detail>
        </soap:Fault>
    </soap:Body>
</soap:Envelope>
\end{lstlisting}

O elemento Fault precisa conter um faultcode seguido de um elemento
faultstring. O elemento faultcode classifica o erro usando um nome de namespace
adequado, enquanto o elemento faultstring provém uma explanação do erro
inteligível para o homem.

\subsection{Extensibilidade}

A maioria dos protocolos fazem uma distinção entre o controle da informação
(ex: header) e o conteúdo da mensagem, inclusive o SOAP. Além de fácil de usar,
o benefício fundamental de Envelopes extensíveis é que pode ser usado com
qualquer protocolo de comunicação. Os Headers sempre desempenharam um papel
importante nos protocolos de aplicação, como HTTP, SMTP, etc, pois eles
permitem que as aplicações nas duas pontas negociem o comportamento dos
comandos suportados. O elemento Header, assim como o elemento Body, é um
container para controle de informação. Ele pode conter qualquer número de
elementos de qualquer namespace. Elementos colocados no elemento Header são
referidos como header blocks. Assim como em outros protocolos, header blocks
devem conter informações que influenciem no processo de carga.

Os Header Blocks podem ainda serem anotados pelo atributo global SOAP chamado
mustUnderstand, para indicar quando o receptor precisa entender o cabeçalho
antes do processamento da mensagem. O exemplo a seguir ilustra como requisitar
o processamento.

\begin{lstlisting}[style=xml_source_code]
<soap:Envelope
  xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
    <soap:Header>
        <!-- security credentials -->
        <s:credentials xmlns:s="urn:examples-org:security"
          soap:mustUnderstand="1">
            <username>dave</username>
            <password>evad</password>
        </s:credentials>
    </soap:Header>
...
\end{lstlisting}

Se o bloco está anotado com mustUnderstand = “1” e o receptor  não foi
desenhado para suportar o dado header, a mensagem não deveria ser processada e
o Fault deveria retornar para o remetente com o código de status
soap:MustUnderstand.  Quando o mustUnderstand = “0” ou o atributo 
mustUnderstand não está presente, o receptor pode ignorar esses headers e
continuar processando-o. O atributo mustUnderstand desempenha uma regra central
sobre o modelo de processamento SOAP.

\subsection{Modelo de Processo}

O SOAP define um modelo de processamento que delineia as regras para o
processamento de uma mensagem SOAP, assim como as transferências entre o SOAP
remetente e o SOAP receptor.

O modelo de processo permite uma arquitetura mais interessante do que a  vista
anteriormente, pois contém múltiplos nós intermediários, como podemos ver na
figura \ref{fig:troca-de-mensagens-SOAP-mais-sofisticada}.

  \begin{figure}[h]
    \centering
    \includegraphics[width=110mm]{figuras/troca-de-mensagens-SOAP-mais-sofisticada.png}
    \caption{Troca de mensagens SOAP mais sofisticada}
    \label{fig:troca-de-mensagens-SOAP-mais-sofisticada}
  \end{figure}

Um nó intermediário fica entre o remetente e o receptor interceptando mensagens
SOAP. Um intermediário atua tanto como um remetente SOAP como um receptor SOAP
ao mesmo tempo. Nós intermediários tornam possível desenhar algumas arquiteturas
de rede flexíveis que podem ser influenciadas pelo conteúdo da mensagem.
Roteamento SOAP é um bom exemplo de algo que aproveita fortemente os
intermediários do SOAP.

Enquanto processa uma mensagem, um nó SOAP assume uma ou mais regras que
influenciam como os headers SOAP são processados.  As regras recebem um nome
único e com isso podem ser identificadas durante o processamento. Quando o nó
SOAP recebe uma mensagem para processar, precisa primeiro determinar que regras
vai assumir. Isso pode ser consultado na mensagem SOAP para ajudar nessa
determinação.

Uma vez determinadas as regras no qual irá agir, o nó SOAP precisa processar
todos os headers obrigatórios (marcados com mustUnderstand="1") utilizando uma
dessas regras. O nó SOAP precisa ainda escolher se processa os headers
opcionais (marcados com mustUnderstand="0") usando uma dessas regras.

O SOAP 1.1 apenas define uma regra simples nomeada
\textit{http://schemas.xmlsoap.org/soap/actor/next}. Todo nó SOAP precisa
assumir a próxima regra. Por isso, quando uma mensagem SOAP chega em qualquer nó SOAP, o
nó precisa processar todos os headers obrigatórios orientados para a próxima
regra.

Os Headers SOAP carregam uma regra específica por meio do atributo ator global.
Se o atributo ator não está presente, o header é marcado com a última regra
recebido por padrão. A mensagem SOAP ilustra a seguir como usar o ator.

\begin{lstlisting}[style=xml_source_code]
<soap:Envelope
  xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
    <soap:Header>
        <wsrp:path xmlns:wsrp="http://schemas.xmlsoap.org/rp"
          soap:actor="http://schemas.xmlsoap.org/soap/actor/next"
          soap:mustUnderstand="1">
... 
\end{lstlisting}

Desde o wsrp:path header, é destinado para a próxima regra e marcado como
mandatório (mustUnderstand="1". O primeiro nó SOAP a receber essa mensagem é
requisitado para processar isso de acordo com a especificação do bloco do
header, neste caso WS-Routing. Se o nó SOAP não foi desenhado para entender um
header obrigatório designado para uma de suas regras, gera-se uma SOAP fault,
com um status code soap:MustUnderstand e interrompe o processamento.

O elemento SOAP fault provém o elemento filho faultactor para especificar quem
causou a falha que aconteceu dentro do pacote da mensagem. O valor de um
atributo faultactor é uma URI que identifica o nó SOAP que causou a falha. Se
um nó SOAP processar um header com sucesso, ele precisará remover o header da
mensagem.

\subsection{Protocolo Bindings}

O SOAP habilita a troca de mensagens por meio de uma variedade de protocolos.
Uma vez que o framework de mensagens SOAP é independente dos protocolos
subjacentes, cada intermediário pode escolher usar um diferente protocolo de
comunicação sem afetar a mensagem SOAP. Os protocolos Bindings padrões são
necessários para assegurar o alto nível de interoperabilidade através das
aplicações SOAP.

Um protocolo Binding concreto define exatamente como as mensagens SOAP deverão
ser transmitidas e com que protocolo. O que o protocolo Binding realmente
define, depende de muito da capacidade e das opções dos protocolos. Por exemplo,
um protocolo binding para TCP deveria parecer bem diferente de um MSMQ ou SMTP. A
especificação SOAP 1.1 apenas codifica um protocolo binding para HTTP,  devido
a sua ampla utilização.

O SOAP tem sido usado com outros protocolos além do HTTP, mas a implementação
não segue a padronização do binding.

\subsubsection{HTTP Binding}

O protocolo binding HTTP define as regras para usar o SOAP sobre HTTP.  O SOAP
request/response é mapeado naturalmente para o modelo HTTP request/response.  A
figura \ref{fig:modelo-http-request-response} ilustra muitos dos detalhes do SOAP binding HTTP.

  \begin{figure}[h]
    \centering
    \includegraphics[width=75mm]{figuras/modelo-http-request-response.png}
    \caption{Modelo HTTP Request/Response}
    \label{fig:modelo-http-request-response}
  \end{figure}
  
O cabeçalho Content-Type para ambas mensagens HTTP request e response, precisam
ser text/xml (aplicação/soap +xml no SOAP1.2). Quanto a  mensagem de request, é
preciso usar POST para o verbo e a URI deve identificar o processo SOAP. A
especificação SOAP ainda define um novo cabeçalho HTTP chamado SOAPAction, que
precisa estar presente em todas as requisições SOAP HTTP (mesmo as vazias). O
cabeçalho SOAPAction pretende expressar a intenção da mensagem. Quanto ao HTTP
response, este precisa usar o código de status 200 se não ocorrerem erros e 500
se o body contiver um SOAP Fault.

\subsubsection{RPC and Encoding}

Embora a especificação SOAP tenha evoluído longe de objetos, ainda define uma
convenção para encapsulamento e troca de chamadas RPC usando o framework de
mensagens descrito a seguir. Ao se definir um meio padrão de mapear chamadas
RPC para mensagens SOAP faz com que seja possível a infra-estrutura traduzir
automaticamente entre chamadas de métodos e mensagens SOAP em tempo de
execução, sem redesenhar o código ao redor da plataforma Web service.

Para fazer uma chamada a um método usando SOAP, a infra-estrutura precisa
seguir as seguintes informações:

\begin{enumerate}
  \item{Localização do Endpoint (URI)}
  \item{Nome do método}
  \item{Parâmetros names/values}
  \item{Assinatura opcional do método}
  \item{Dados opcionais no cabeçalho}
\end{enumerate}

Essa informação pode ser transmitida de diversas maneiras inclusive por
bibliotecas, arquivos IDL ou arquivos WSDL. O binding do SOAP RPC define como
encapsular e representar essa informação dentro do SOAP body. Faz-se isso
definindo primeiramente como a assinatura do método mapeia uma estrutura
simples de request/response, que possa ser codificada como XML. Os estados de
binding RPC que chamam o método serão modelados como uma estrutura nomeada
depois do método. A estrutura conterá um acessor para cada parâmetro [in] ou
[in/out], nomeado igual ao nome do parâmetro, e na ordem definidos pela
assinatura da mensagem. O método response vai também ser modelado como uma
estrutura. O nome da estrutura é insignificante ainda que a convenção seja usar
o nome do método seguido pela “Response”. A estrutura de response contém um
acessor para retornar valores seguidos pelos acessores para cada parâmetro [out]
ou [in/out].

O exemplo a seguir é um método C\# para uma operação add:

\begin{lstlisting}[style=c_source_code]
double add(ref double x, double y)
\end{lstlisting}

De acordo com as regras de binding RPC descritas, a estrutura de request
representada na chamada de método deveria ser modelada como abaixo:

\begin{lstlisting}[style=c_source_code]
struct add {
    double x;
    double y;
}
\end{lstlisting} 

Enquanto a estrutura de resposta deve parecer com a que segue abaixo:

\begin{lstlisting}[style=c_source_code]
struct addResponse {
	double result;
	double x;
}
\end{lstlisting} 

A estrutura mapeada para XML segue a especificação SOAP que define um conjunto
de regras de codificação. As regras de codificação do SOAP delimitam como
mapear a maioria das estruturas de dados mais comumente usadas (como structs e
arrays), para um formato XML comum.

De acordo com as regras de codificação SOAP, a estrutura de request vista acima
deve mapear a seguinte mensagem XML:

\begin{lstlisting}[style=XML_source_code]
<add>
    <x>33</x>
    <y>44</y>
</add>
\end{lstlisting}

A mensagem de resposta para a apresentada anteriormente deve ser mapeada na
seguinte mensagem XML: 

\begin{lstlisting}[style=XML_source_code]
<addResponse>
    <result>77</result>
    <x>33</x>
</addResponse>
\end{lstlisting}

\chapter{Tradução para o JavaScript}

\section{Objetos auxiliares para comunicação}\label{Objetos auxiliares para
comunicação}

Foi necessário desenvolver o código JavaScript responsável por toda a
comunicação com os Web Services. Esse código é independente do WSDL lido e pode
ser usado com qualquer Web Service que troque mensagens utilizando o protocolo
SOAP nas versões 1.1 e 1.2. As sub-seções \ref{SOAPAction}  e \ref{Utils}
mostram em detalhes as principais funcionalidades desses dois objetos
auxiliares.

\subsection{SOAPAction}\label{SOAPAction}

O primeiro objeto apresentado será o SOAPActions, que assim como outros que
iremos apresentar, é um objeto que possui conteúdo independentemente dos
Web Services utilizados, pois tem funções necessárias para qualquer Web Service.


Sua principal função se restringe a montar corretamente uma mensagem SOAP,
enviá-la ao endereço dos Web Services utilizando AJAX, e receber a resposta em
XML. O tratamento das mensagens e conversão do XML para uma estrutura de dados
em Java Script, não é abordada pelo SOAPActions.

A primeira chamada apenas faz uma distinção de acordo com a preferência do
usuário por uma requisição assíncrona ou síncrona.

\begin{lstlisting}[style = js_source_code]
// Initializes the Request by differing asynchronized operation from synchronized 
    call: function(location, 
                   inMethod, 
                   outMethod, 
                   namespace, 
                   soapaction, 
                   async,
                   inParam, 
                   outParam) { 
    if(async)
        SOAPActions.chargeMessage (location, 
                                   inMethod, 
                                   outMethod, 
                                   namespace,
                                   soapaction, 
                                   async, 
                                   inParam, 
                                   outParam); 
    else
        return SOAPActions.chargeMessage (location, 
                                          inMethod, 
                                          outMethod,
                                          namespace, 
                                          soapaction, 
                                          async, 
                                          inParam, 
                                          outParam); 
}
\end{lstlisting}

A mensagem SOAP é montada com os dados passados pelo usuário
no objeto “inParam”, acrescido das informações pertinentes a mensagem que os
Web Services esperam receber.

\begin{lstlisting}[style = js_source_code]
// Cria a mensagem SOAP
if (soapVersion = "1.1")
    var message = 
        "<?xml version=\"1.0\" encoding=\"utf-8\"?>" +
        "<soap:Envelope " +
        "xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" " +
        "xmlns:xsd=\"http://www.w3.org/2001/XMLSchema\" " +
        "xmlns:soap=\"http://schemas.xmlsoap.org/soap/envelope/\">" +
        "<soap:Body>" +
        "<" + operation + " xmlns=\"" + namespace + "\">" +
        Utils.objectToXml(inParam) +
        "</" + operation + "></soap:Body></soap:Envelope>";
else if (soapVersion = "1.2")
    var message =
        "<?xml version=\"1.0\" encoding=\"utf-8\"?>" +
        "<soap12:Envelope " +
        "xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" " +
        "xmlns:xsd=\"http://www.w3.org/2001/XMLSchema\" " +
        "xmlns:soap12=\"http://www.w3.org/2003/05/soap-envelope\">" +
        "<soap12:Body>" +
        "<" + operation + " xmlns=\"" + namespace + "\">" +
        Utils.objectToXml(inParam) +
        "</" + operation + "></soap12:Body></soap12:Envelope>";
else throw new Error (500, "Versão SOAP para a construção da mensagem não
identificada");
...
\end{lstlisting}

Com a mensagem pronta, é necessário abrir uma conexão utilizando AJAX para
que se possa trocar mensagens com o domínio dos Web Services. A troca de
mensagens é efetuada com as tradicionais distinções para o caso de o usuário
desejar receber uma resposta assíncrona.


\begin{lstlisting}[style = js_source_code]
// Envia a requisição
    var xmlHttp = Utils.getXmlHttp(); 
    xmlHttp.open("POST", location, async);
    xmlHttp.setRequestHeader("SOAPAction", soapaction);
    xmlHttp.setRequestHeader("Content-Type", "text/xml; charset=utf-8");
    if(async) {
        xmlHttp.onreadystatechange = function() {
            if(xmlHttp.readyState == 4)
                SOAPActions.chargedMessage(operation, 
                                           operationResponse,
                                           outMethod, 
                                           async, 
                                           xmlHttp, 
                                           outParam); 
        }
    }
    xmlHttp.send(message);
    if (!async)
        return SOAPActions.chargedMessage(operation, 
                                          operationResponse,
                                          outMethod, 
                                          async, 
                                          xmlHttp, 
                                          outParam);
}
\end{lstlisting}

A função “chargedMessage” é chamada para tratar a resposta, a mensagem XML é
traduzida para o formato de Nodos pela API DOM do Java Script, tratada por uma
função do objeto “Utils” e a função de retorno é executada com a resposta
devidamente convertida para a estrutura de dados organizada no objeto JavaScript
Schema.

\begin{lstlisting}[style = js_source_code]
chargedMessage: function(operation, 
                         operationResponse, 
                         outMethod, 
                         async, 
                         xmlHttp, 
                         outParam){
// Aloca a resposta SOAP em uma estrutura de Nó utilizando a API DOM.
var ResponseNode = Utils.getNode(xmlHttp, operationResponse);
//Converte a estrutura de Nó para a estrutura de dados de outParam (Objeto)
outParam = Utils.nodeToObject(ResponseNode, outParam);
// E retorna a resposta
outMethod(outParam);
if(!async)
    return outParam;
}	
\end{lstlisting}

\subsection{Utils} \label{Utils}

O objeto Utils tem como função principal manter funções que serão necessárias
durante todo o processo. Devido ao fato de este objeto ter ficado
relativamente grande e ser utilizado para os mais diversos tipos de funções,
iremos apenas mostrar as funções que apresentaram maior influência no resultado
final do projeto.

\subsubsection{objectsToXML}

É a função responsável por escrever a parte dos dados provenientes do
objeto JavaScript Schema em XML. Este método não se preocupa em incluir o
primeiro objeto da hierarquia na conversão, pois ele possui o mesmo nome da operação a ser
chamada nos Web Services e seria redundante colocá-lo no corpo da mensagem,
ocasionando erro de formatação e o não entendimento da mensagem por parte dos
Web Services.

\begin{lstlisting}[style = js_source_code]
// converte a estrutura de dados utilizada para tags XML
    objectToXml: function (obj) {
        xmlStr = "";
        for (var i in obj.getAttr()[0]) {
            xmlStr += Utils.buildTag (obj.getAttr()[0][i]);//t? feio
        }
        return xmlStr;
    },

    // função que complementa a anterior
    buildTag: function (obj) {
        var strTag = "";
        if (obj.getType() == "Complex") {
            if (obj.getAttr().length > 0) {
                strTag += "<" + obj.getName() + ">";
                for (var p in obj.getAttr()) 
                    for (var i in obj.getAttr()[p]) 
                        strTag += Utils.buildTag (obj.getAttr()[p][i]);
                strTag += "</" + obj.getName() + ">";
            }
        } else {
            if (obj.getValue() != undefined) {
                strTag += "<" + obj.getName() + ">";
                strTag += obj.getValue().replace(/&/g, "&amp;").replace(/</g,"&lt;").
                                                                replace(/>/g,"&gt;");
                strTag += "</" + obj.getName() + ">";
            }
        }
        return strTag;
    }

\end{lstlisting}

\subsubsection{nodeToObject}

Esta função recebe como parâmetros uma árvore de nós, retirada da resposta XML
enviada pelos Web Services, e o objeto que deve possuir estrutura similar para
que a conversão funcione. Este método busca todos os valores incluídos na
árvore e procura seu par na estrutura de objetos decalrados no objeto
JavaScript Schema, descendo na hierarquia de objetos de
forma idêntica até que se encontre um nó folha e busque o seu valor com auxílio da função getValue, demonstrada logo
abaixo.

\begin{lstlisting}[style = js_source_code]
// Constrói um objeto do tipo OutParam se baseando na árvore de nós
nodeToObject: function(node, outParam) {
    if (node == null)
        return null;
    // Se o nó for do tipo texto, então retorna seu valor final
    if (node.nodeType == 3 || node.nodeType == 4)
        return Utils.getValue(node, outParam);
    nodeLocalName = Utils.getNodeLocalName(node);
    // Apenas continua se o nodeName existir no objeto outParam, caso contrário
    ocorre um erro 
    if (outParam.getName() == nodeLocalName) {
        // Se for um nó folha retorna o m?todo recursivamente chamando o nó
        filho para o mesmo outParam 
        if (Utils.isLeafNode(node)) {
            return Utils.nodeToObject(node.childNodes[0], outParam);
        }
        for(var i = 0; i < node.childNodes.length; i++) { 
            var pos = Utils.getSameNodesPosition (node.childNodes[i]);
            var p = Utils.nodeToObject(node.childNodes[i],
                            outParam.getAAttr(Utils.getNodeLocalName(node.childNodes[i]),
                            pos)); 
           outParam.setAAttr(p, 
                             Utils.getNodeLocalName(node.childNodes[i]),
                            pos); 
        } 
        return outParam;
    }
    throw new Error (500, "Erro na convers?o de n?s para objetos");
}

// Retorna um valor baseando-se no objeto que estaria destinado a receber o valor
getValue: function(node, outParam) {
    var value = node.nodeValue;
    switch(outParam.getType()) {
        case "String":
            (value != null) ? outParam.setValue(value + ""):outParam.setValue(""); 
            return outParam; 
        case "Boolean":
            outParam.setValue((value + "").toLowerCase() == "true");
            return outParam;
        case "Number":
            if (value % 2 == 0 || value % 2 == 1 || value % 2 == -1)
                outParam.setValue(parseInt(value + "", 10));
            else
                (value != null) ? outParam.setValue(parseFloat(value + "")) :
                                                        outParam.setValue(0);
            return outParam;
        default:
            throw new Error (500, "Tipo do objeto mal formatado.");
    }
}

\end{lstlisting}

\section {Tradução Manual do Web Service AWSECommerce}

\subsection{Objetivo}
Como objetivo primário, utilizamos uma abordagem bottom-up, em que escolhemos
um Web Service específico. Escrevemos um stub em Java Script manualmente e
avaliamos os resultados da utilização do stub juntamente com o Web Service.

Com o intuito de obter resultados mais convincentes, optamos por utilizar o Web
Service AWSECommerce da empresa Amazon, que é amplamente utilizado pelos mais
diversos tipos de aplicação e suficiente para enxergarmos, na prática, como o
funcionamento do Web Service é descrito no arquivo WSDL.

Durante a tradução manual, feita como um primeiro passo do projeto, criamos um
arquivo Javascript referente ao stub com o mesmo nome do arquivo WSDL utilizado
para a tradução, neste caso AWSECommerceService.js.

\subsection{Criação da estrutura de dados baseada no XMLSchema}

Cada operação descrita em um arquivo WSDL utiliza uma estrutura bem definida
para mensagens de entrada e saída, descritas respectivamente em suas tags input
e output.\\

\begin{lstlisting}[style = xml_source_code]
<operation name="ItemSearch" ... >
    <input messageLabel="In" element="tns:ItemSearch"/>
    <output messageLabel="Out" element="tns:ItemSearchResponse"/>
</operation>
\end{lstlisting}

Devido ao fato de o JavaScript não ser uma linguagem fortemente tipada, seria
inviável a utilização de suas variáveis em sua forma básica para representação
dos elementos do XMLSchema, por isso se torna necessária a criação de uma
estrutura (WsdlObject) que possa resumir as informações de cada ``Element''. \\

\begin{lstlisting}[style = js_source_code]
function WsdlObject() {
    ...
}
\end{lstlisting}

A proposta dessa nova função é a de guardar três informações básicas de um
objeto XMLSchema: seu nome, tipo (Complexo ou Simples) e valor,  assim como
fornecer métodos getters e setters para o gerenciamento das mesmas. Essas
informações devem ser fornecidas no momento da criação da instância através de
parâmetros. \\

\begin{lstlisting}[style = js_source_code]
function WsdlObject(_name, _type, _value) {
    var name = _name;
    var type = _type; //ComplexType (Complex), SimpleType (Simple)
    var value = _value;

    this.getName = function () {
        return name;
    }
    
    this.setName = function (_name) {
        name = _name;
    }

    this.getType = function () {
        return type;
    }

    this.setType = function (_type) {
        type = _type;
    }

    this.getValue = function () {
        return value;
    }

    this.setValue = function (_value) {
        value = _value;
    }
    
    ...
}
\end{lstlisting}

Além das informações triviais, é necessário que um WsdlObject armazene as
informações dos seus subelementos, como demonstrado no exemplo acima. É
importante frisar que cada Element pode existir mais de uma vez na mensagem XML
caso não seja apresentado o atributo maxOccurs=``1''. Por este motivo, também é
indispensável o armazenamento da posição de cada subelemento. Para este fim o
uso de uma matriz seria ideal, mas como o Javascript não fornece este tipo de
estrutura, a solução encontrada foi a criação de dois vetores, chamados
``attr'' e``elementsArray''. O primeiro guardará uma posição, enquanto o segundo
armazena todos os subelementos do objeto, como ilustrado na figura
\ref{fig:WsdlObjectsArrays}. \\

\begin{lstlisting}[style = xml_source_code]
<xs:complexType name="tStadiumInfo"> 
    <xs:sequence> 
        <xs:element name="sStadiumName" type="xs:string"/>
        ...
        <xs:element name="sGoogleMapsURL" type="xs:string"/> 
    </xs:sequence> 
</xs:complexType>
\end{lstlisting} 

\begin{figure}[h]
    \centering
    \includegraphics[width=200mm]{figuras/wsdlObjectArrays.png}
    \caption{WsdlObjectArrays}
    \label{fig:WsdlObjectsArrays}
\end{figure}
 
Assim existem getters and setters para as variáveis básicas, funções para o
gerenciamento dos subelementos também devem ser criadas, neste caso quatro
funções fazem este papel.
\begin{itemize}
  \item{addElement simplesmente adiciona o objeto do tipo WsdlObject recebido ao vetor elementArray.}
  \item{getAAttr retorna um subelemento pelo nome e posição, sendo o argumento da posição opicional. Caso a posição não seja especificada, assume-se a primeira como requerida.}
  \item{setAAttr é semelhante a anterior, diferenciando-se por requisitar um objeto do tipo WsdlObject como argumento adicional.}
  \item{newAttr inicializa uma nova posição no vetor attr com os elementos do vetor elementsArray.}
\end{itemize}

\begin{lstlisting}[style = js_source_code]
function WsdlObject(_name, _type, _value) {
    var name = _name;
    var type = _type; //ComplexType (Complex), SimpleType (Simple)
    var value = _value;
    var attr = new Array();
    var elementsArray = new Array();
    
    this.addElement = function(_obj) {
        elementsArray.push(_obj);
    }
        
    this.getAAttr = function(_name, _pos) {
        if (_pos == undefined) _pos = 0;
        if (_pos > attr.length) throw new Error (500, "Tentativa de recuperar uma posi��o inexistente");
        if (_pos == attr.length) {
            this.newAttr();
        }
        for (var p in attr[_pos]) {
            if (_name == attr[_pos][p].getName()) {
                return attr[_pos][p];
            }
        }
    }

    this.setAAttr = function(_attr, _name, _pos) {
        if (_pos == undefined) _pos = 0;
        if (_pos > attr.length) throw new Error (500, "Tentativa de fazer uma atribui��o fora da ordem.");
        if (_pos == attr.length) {
            this.newAttr();
        }
        for (var p in attr[_pos]) {
            if (_name == attr[_pos][p].getName()) {
                attr[_pos][p] = _attr;
            }
        }
    }

    this.newAttr = function() {
        var i = attr.length;
        attr[i] = new Array();
        for (var p in elementArray) {
            attr[i].push(p);
        }
    }
}
\end{lstlisting}

Com esta estrutura definida, a tradução do XMLSchema torna-se mais simples.  

% parei aqui 

% \begin{lstlisting}[style = js_source_code]
% function WsdlObject(_name, _type, _value) {
%     var name = _name;
%     var type = _type;
%     var value = _value;
%     var attr = new Array();
%     var elementsArray = new Array();
% 
%     this.getName = getName;
%     this.getType = getType;
%     this.getValue = getValue;
%     this.getAttr = getAttr;
%     this.setName = setName;
%     this.setType = setType;
%     this.setValue = setValue;
%     this.setAttr = setAttr;
%     this.addElement = addElement;
% 
%     this.getAAttr = getAAttr;
%     this.setAAttr = setAAttr;
%     this.newAttr = newAttr;
% 
%     function getName() {
%         return name;
%     }
% 
%     function getType() {
%         return type;
%     }
% 
%     function getValue() {
%         return value;
%     }
% 
%     function getAttr() {
%         return attr;
%     }
% 
%     function setName(_name) {
%         name = _name;
%     }
% 
%     function setType(_type) {   
%         type = _type;
%     }
% 
%     function setValue(_value) {   
%         value = _value;
%     }
% 
%     function setAttr(_attr) {
%         attr = _attr;
%     }
% 
%     function addElement(_obj) {
%         elementsArray.push(_obj);
%     }
% 
%     function getAAttr(_name, _pos) {
%         if (_pos == undefined) _pos = 0;
%         if (_pos > attr.length){
%          throw new Error (500, "Tentativa de recuperaruma posição inexistente");
%        }
%         if (_pos == attr.length) {
%              this.newAttr();
%         }
%         for (var p in attr[_pos]) {
%             if (_name == attr[_pos][p].getName()) {
%                 return attr[_pos][p];
%             }
%         }
%     }
% 
%     function setAAttr(_attr, _name, _pos) {
%         if (_pos == undefined) _pos = 0;
%         if (_pos > attr.length){ 
%          throw new Error (500, "Tentativa de fazer uma atribuição fora da
%            ordem.");
%         }
%         if (_pos == attr.length) {
%             this.newAttr();
%         }
%         for (var p in attr[_pos]) {
%             if (_name == attr[_pos][p].getName()) {
%                 attr[_pos][p] = _attr;
%             }
%         }
%     }
% 
%     function newAttr() {
%         var i = this.getAttr().length;
%         this.getAttr()[i] = new Array();
%         for (var j = 0; j < elementsArray.length; j++) {
%             this.getAttr()[i].push(elementsArray[j]);
%         }
%     }
% }
% \end{lstlisting}

{\LARGE Incompleto}

% Em um objeto específico é armazenada toda a estrutura de dados contida no
% arquivo WSDL em questão.
% 
% Acima, temos a Operação ItemSearch que recebe uma mensagem do tipo
% ItemSearchRequestMsg e devolve uma mensagem do tipo ItemSearchResponseMsg.\\
% 
% 
% Ambas precisam ser mapeadas para que possamos saber que tipo de elemento é
% trocado por estas mensagens. Vamos avaliar, como exemplo para essa tradução, a
% ItemSearchRequestMsg que podemos ver abaixo.\\
% 
% \begin{lstlisting}[style = xml_source_code]
% <message name="ItemSearchRequestMsg">
%    <part name="body" element="tns:ItemSearch"/>
% </message>
% \end{lstlisting}
% 
% Essa mensagem troca informações por meio do elemento ItemSearch, como esse não é
% um elemento do tipo primitivo, procuramos a definição de ItemSearch no próprio
% arquivo WSDL para saber que elementos esse objeto encapsula. 
% 
% \begin{lstlisting}[style = xml_source_code]
% <xs:element name="ItemSearch">
%     <xs:complexType>
%         <xs:sequence>
%             <xs:element name="MarketplaceDomain" type="xs:string"
%             minOccurs="0"/> 
%             <xs:element name="AWSAccessKeyId" type="xs:string" minOccurs="0"/>
%                 <xs:element name="SubscriptionId" type="xs:string"
%                 minOccurs="0"/> 
%             <xs:element name="AssociateTag" type="xs:string" minOccurs="0"/>
%             <xs:element name="XMLEscaping" type="xs:string" minOccurs="0"/>
%             <xs:element name="Validate" type="xs:string" minOccurs="0"/>
%             <xs:element name="Shared" type="tns:ItemSearchRequest"
%             minOccurs="0"/>
%             <xs:element name="Request" type="tns:ItemSearchRequest"
%             minOccurs="0" maxOccurs="unbounded"/> 
%         </xs:sequence>
%     </xs:complexType>
% </xs:element>
% \end{lstlisting}
% 
% Como podemos ver, o ItemSearch é um complexType composto por alguns elementos
% primitivos, todos strings, e por mais dois elementos complexos do tipo
% ItemSearchRequest. Logo, a busca recursiva precisa continuar a ser feita para
% que só se encontre elementos de tipos primitivos.\\
% 
% 
% Abaixo, vemos o elemento do tipo ItemSearchRequest, que é um enorme elemento com
% campos para a busca de livros no qual são todos de tipos primitivos. 
% 
% \begin{lstlisting}[style = xml_source_code]
% <xs:complexType name="ItemSearchRequest">
%     <xs:sequence>
%         <xs:element name="Actor" type="xs:string" minOccurs="0"/>
%             <xs:element name="Artist" type="xs:string" minOccurs="0"/>
%         <xs:element name="Availability" minOccurs="0">
%         <xs:element ref="tns:AudienceRating" minOccurs="0"
%         maxOccurs="unbounded"/>
%         <xs:element name="Author" type="xs:string" minOccurs="0"/>
%         <xs:element name="Brand" type="xs:string" minOccurs="0"/>
%         <xs:element name="BrowseNode" type="xs:string" minOccurs="0"/>
%         <xs:element name="City" type="xs:string" minOccurs="0"/>
%         <xs:element name="Composer" type="xs:string" minOccurs="0"/>
%         <xs:element ref="tns:Condition" minOccurs="0"/>
%         <xs:element name="Conductor" type="xs:string" minOccurs="0"/>
%         <xs:element name="Count" type="xs:positiveInteger" minOccurs="0">
%         <xs:element name="Cuisine" type="xs:string" minOccurs="0"/>
%         <xs:element ref="tns:DeliveryMethod" minOccurs="0"/>
%         <xs:element name="Director" type="xs:string" minOccurs="0"/>
%             <xs:element name="FutureLaunchDate" type="xs:string" minOccurs="0"/>
%             <xs:element name="ISPUPostalCode" type="xs:string" minOccurs="0"/> 
% 	    <xs:element name="ItemPage" type="xs:positiveInteger"minOccurs="0"/> 
% 	    <xs:element name="Keywords" type="xs:string" minOccurs="0"/>
%         <xs:element name="Manufacturer" type="xs:string" minOccurs="0"/>
%         <xs:element name="MaximumPrice" type="xs:nonNegativeInteger"
%         minOccurs="0"/> 
%         <xs:element name="MerchantId" type="xs:string" minOccurs="0"/>
%         <xs:element name="MinimumPrice" type="xs:nonNegativeInteger"
%         minOccurs="0"/>
%         <xs:element name="MusicLabel" type="xs:string" minOccurs="0"/>
%         <xs:element name="Neighborhood" type="xs:string" minOccurs="0"/>
%         <xs:element name="Orchestra" type="xs:string" minOccurs="0"/>
%         <xs:element name="PostalCode" type="xs:string" minOccurs="0"/>
%         <xs:element name="Power" type="xs:string" minOccurs="0"/>
%         <xs:element name="Publisher" type="xs:string" minOccurs="0"/>
%         <xs:element name="RelatedItemPage" type="tns:positiveIntegerOrAll"
%         minOccurs="0"/>
%         <xs:element name="RelationshipType" type="xs:string" minOccurs="0"
%         maxOccurs="unbounded"/>
%         <xs:element name="ResponseGroup" type="xs:string" minOccurs="0"
%         maxOccurs="unbounded"/>
%         <xs:element name="ReviewSort" type="xs:string" minOccurs="0"/>
%         <xs:element name="SearchIndex" type="xs:string" minOccurs="0"/>
%         <xs:element name="Sort" type="xs:string" minOccurs="0"/>
%         <xs:element name="State" type="xs:string" minOccurs="0"/>
%         <xs:element name="TagPage" type="xs:positiveInteger" minOccurs="0"/>
%         <xs:element name="TagsPerPage" type="xs:positiveInteger" minOccurs="0"/>
%         <xs:element name="TagSort" type="xs:string" minOccurs="0"/>
%         <xs:element name="TextStream" type="xs:string" minOccurs="0"/>
%         <xs:element name="Title" type="xs:string" minOccurs="0"/>
%         <xs:element name="ReleaseDate" type="xs:string" minOccurs="0"/>
%     </xs:sequence>
% </xs:complexType>
% \end{lstlisting}
% 
% Com isso, já é possível montar o objeto usado na mensagem ItemSearchRequestMsg.
% Escolhendo o atributo “Title” como exemplo e usando o mesmo padrão para a
% mensagem ItemSearchResponseMsg montamos no arquivo Elements.js o objeto
% ItemSearchResponse, como podemos ver abaixo.
% 
% \begin{lstlisting}[style = js_source_code]
% itemSearchRequest = function() {
%     this.Keywords = " ";
%     this.SearchIndex =  " " ;
% }
% 	
% itemSearch = function() {
%     this.AWSAccessKeyId = " ";
%     this.Request = new itemSearchRequest ();
% }
% 	
% itemAttributes = function () {
%     this.Title = " ";
% }
% 	
% _item = function () {
%     this.ASIN = " ";
%     this.ItemAttributes = new itemAttributes();
% } 
% 	
% items = function () {
%     this.Item = new Array();
%     this.Item[0] = new _item();
%     this.Item[1] = new _item();
%     this.Item[2] = new _item();
%     this.Item[3] = new _item();
%     this.Item[4] = new _item();
%     this.Item[5] = new _item();
%     this.Item[6] = new _item();
%     this.Item[7] = new _item();
%     this.Item[8] = new _item();
%     this.Item[9] = new _item();	
% }
% 
% itemSearchResponse = function () {
%     this.Items = new items();
% }
% \end{lstlisting}
% 
% Esse padrão é seguido até que todos os objetos de todas as mensagens sejam
% mapeados no arquivo Elements.js.\\


\subsection{Tradução Manual das operações descritas no WSDL}

Para se fazer a tradução, definimos que todas as operações (métodos) deveriam
estar contidas em algum objeto. Assim como ocorre no WSDL, onde as operações são
definidas através do componente Binding especificado por um Endpoint, que
pertence a um Service, por sua vez.

Criamos um objeto mais abrangente com o nome do serviço (AWSECommerceService), 
que define objetos com o nome de cada Endpoint (AWSECommerceServicePort). Este
objeto mais interno fica responsável por conter os métodos do Binding
correspondente que poderão ser chamados pelo usuário do Stub. \\

\begin{lstlisting}[style = xml_source_code]
<service name="AWSECommerceService"
         interface="tns:AWSECommerceServicePortType">
    <endpoint name="AWSECommerceServicePort"
              binding="tns:AWSECommerceServiceBinding"
              address="https://ecs.amazonaws.com/onca/soap?Service=AWSECommerceService">
    </endpoint>
</service>
\end{lstlisting}

\begin{lstlisting}[style = js_source_code]
AWSECommerceService = {

    AWSECommerceServicePort: {
        ...
    }
}
\end{lstlisting}

Algumas informações importantes são necessárias para se fazer as requisições ao
Web Service, como o targetNamespace do WSDL, a URL contida no atributo address
de cada Endpoint e a versão da mensagem SOAP que será trocada com o servidor.

O targetNamespace é único e independe do serviço para todo o arquivo
WSDL, mas como o objeto mais amplo definido foi o ``AWSECommerceService'',
um atributo com esta especificação precisa ser declarado dentro deste objeto. O
address é um atributo específico do Endpoint e portanto deve ser incluída no
respectivo objeto do Javascript. A versão da mensagem SOAP é armazenada na
extensão version, localizada na tag <binding> referenciada pelo Endpoint. \\

\begin{lstlisting}[style = xml_source_code]
<description
targetNamespace="http://webservices.amazon.com/AWSECommerceService/2009-07-01" ... >
\end{lstlisting}

\begin{lstlisting}[style = xml_source_code]
<endpoint name="AWSECommerceServicePort"
          ...
          address="https://ecs.amazonaws.com/onca/soap?Service=AWSECommerceService">
\end{lstlisting}

\begin{lstlisting}[style = xml_source_code]
<binding name="AWSECommerceServiceBinding"
         ...
         wsoap:version="1.1">
\end{lstlisting}

\begin{lstlisting}[style = js_source_code]
AWSECommerceService = {

    namespace: "http://webservices.amazon.com/AWSECommerceService/2009-07-01",
    
    AWSECommerceServicePort: {
    
        address: "https://ecs.amazonaws.com/onca/soap?Service=AWSECommerceService",

        soapVersion: "1.1",
    
        ...     
    } 
}
\end{lstlisting}

Após a definição destes objetos, a tradução das operações do arquivo
WSDL pode ser feita para Javascript. Para isso, é necessário pesquisar qual
Binding está associado ao Endpoint em questão comparando o atributo ``binding'' do
Endpoint com o atributo ``name'' das Bindings, como visto acima. No caso a
``AWSECommerceServiceBinding''. 

Para cada operação dentro do Binding, uma função deverá ser criada no
Javascript. No exemplo abaixo, o conteúdo do atributo ``ref'' é utilizado como
nome da função e o atributo ``action'' é armazenado em uma variável da função.

Dois parâmetros de entrada são requisitados ao usuário, ``body'' e
``outMethod''. O primeiro deverá conter uma instância do objeto ``Schema'', que contém a
estrutura de dados necessária para que a mensagem SOAP enviada seja montada
corretamente. O segundo é a função de retorno que irá receber a resposta do
servidor, já adaptada a estrutura mencionada anteriormente. \\

\begin{lstlisting}[style = xml_source_code]
<binding name="AWSECommerceServiceBinding"
         ...>
    <operation ref="tns:Help" wsoap:action="http://soap.amazon.com/Help">
    </operation>
    
    <operation ref="tns:ItemSearch" wsoap:action="http://soap.amazon.com/ItemSearch">
    </operation>
\end{lstlisting}

\begin{lstlisting}[style = js_source_code]
AWSECommerceService = {

    namespace: "http://webservices.amazon.com/AWSECommerceService/2009-07-01",
    
    AWSECommerceServicePort: {
    
        address: "https://ecs.amazonaws.com/onca/soap?Service=AWSECommerceService",

        soapVersion: "1.1",
    
        ItemSearch: function (body, outMethod) {
        	var operation = "ItemSearch";
            var action = "http://soap.amazon.com/ItemSearch";
            ...
        },
        
        Help: function (body, outMethod) {
        	var operation = "Help";
            var action = "http://soap.amazon.com/Help";
            ...
        }
        
    }
}
\end{lstlisting}

A Binding em questão está atrelada a uma interface. Esta ligação se dá pelo seu
atributo ``interface'', assim como os seus ``operations'', que fazem referência
aos da interface. O output ``element'' também é necessário para complementar as
funções escritas no código Javascript de modo a criar o objeto que conterá as
informações retornadas através da mensagem SOAP.

Em seguida é feita uma chamada a função responsável por efetuar a troca das
mensagens e chamar a função de retorno do usuário, passando todas as informações
relevantes como parâmetro.
\\

\begin{lstlisting}[style = xml_source_code]
<binding name="AWSECommerceServiceBinding"
         interface="tns:AWSECommerceServicePortType"
         ...>
    <operation ref="tns:Help" wsoap:action="http://soap.amazon.com/Help">
    </operation>
    
    <operation ref="tns:ItemSearch" wsoap:action="http://soap.amazon.com/ItemSearch">
    </operation>
\end{lstlisting}

\begin{lstlisting}[style = xml_source_code]
<interface name="AWSECommerceServicePortType">
    <operation name="Help"
               pattern="http://www.w3.org/ns/wsdl/in-out">
      <input messageLabel="In" element="tns:Help"/>
      <output messageLabel="Out" element="tns:HelpResponse"/>
    </operation>
    <operation name="ItemSearch"
               pattern="http://www.w3.org/ns/wsdl/in-out">
      <input messageLabel="In" element="tns:ItemSearch"/>
      <output messageLabel="Out" element="tns:ItemSearchResponse"/>
    </operation>
\end{lstlisting}

\begin{lstlisting}[style = js_source_code]
AWSECommerceService = {

    namespace: "http://webservices.amazon.com/AWSECommerceService/2009-07-01",
    
    AWSECommerceServicePort: {
    
        address: "https://ecs.amazonaws.com/onca/soap?Service=AWSECommerceService",

        soapVersion: "1.1",
    
        ItemSearch: function (body, outMethod) {
            var operation = "ItemSearch";
            var output = "ItemSearchResponse";
            var action = "http://soap.amazon.com/ItemSearch";
            var outParam = Schema.getAAttr("ItemSearchResponse");
            SOAPActions.call(AWSECommerceService.AWSECommerceServicePort.address,
                             operation,
                             output,
                             outMethod,
                             AWSECommerceService.namespace,
                             action,
                             true,
                             body,
                             outParam,
                             AWSECommerceService.AWSECommerceServicePort.soapVersion);
        },

        Help: function (body, outMethod) {
            var operation = "Help";
            var output = "HelpResponse";
            var action = "http://soap.amazon.com/Help";
            var outParam = Schema.getAAttr("HelpResponse");
            SOAPActions.call(AWSECommerceService.AWSECommerceServicePort.address,
                             operation,
                             output,
                             outMethod,
                             AWSECommerceService.namespace,
                             action,
                             true,
                             body,
                             outParam,
                             AWSECommerceService.AWSECommerceServicePort.soapVersion);
        },        
    }
}
\end{lstlisting}

\chapter{Implementação do Gerador Automático}
\section{Estrutura de um Tradutor}
O trabalho de um tradutor pode ser dividido basicamente em três partes:

\begin{itemize}
  \item{Análise léxica.}
  \item{Análise Sintática.}
  \item{Geração do Código}
\end{itemize}

A análise léxica é o processo de converter uma sequência de caracteres em uma
sequência de tokens. Analisadores léxicos consistem em um “scanner” e um
tokenizer e podem ser entendidos como um validador. A função de um analisador
léxico é dividir uma entrada de fluxo de caracteres em tokens. 

A análise sintática, também conhecida como parsing, é o processo de analisar
uma sequência de tokens para determinar a sua estrutura gramatical e se esta
sequência atende as especificações sintáticas de uma gramática formal. 

Para a implementação, utilizamos a API Apache Woden como analisador
léxico e sintático. Um fator importante para essa escolha foi a prévia
utilização desta ferramenta para a conversão do WSDL 1.1 para o WSDL 2.0,
possibilitando que só fosse  preciso desenvolver a tradução da versão 2.0 do
WSDL para atender as duas versões. 
	
Tendo os processos de parsing e scanner sido executados com sucesso, e não
gerado nenhum erro, o sistema terá uma representação interna do WSDL a qual
pode ser facilmente manipulada pelo último estágio do tradutor: o gerador de
código, que ao contrário dos analisadores léxico e sintático, precisa ser
escrito manualmente a fim de se obter o comportamento desejado.


\section{Apache Woden}\label{Apache Woden}

O objetivo inicial do projeto Woden é desenvolver um processador de WSDL 2.0
que implementa a especificação de WSDL 2.0 do W3C. O segundo objetivo inclui o
suporte para parsing de XML com alto desempenho e o suporte para WSDL 1.1. 

O processador de WSDL do Woden é implementado como um framework com pontos de
extensão para que o usuário possa definir o seu comportamento. O Woden é uma API
baseada em DOM e por isso possui as propriedades de tratar XML. A API Woden
contém duas ``sub-APIs'' que representam modelos alternativos do objeto WSDL 2.0:

\begin{itemize}
	\item{A API Element representa um modelo dos elementos e atributos XML
	no WSDL 2.0 namespace, como descrito pelo mapeamento XML na especificação do
	WSDL 2.0.}
	\item{A API Component representa um modelo abstrato do componente WSDL
	descrito pela especificação WSDL 2.0.}
\end{itemize} 

\subsubsection{API Element}
A API Element permite a navegação pela hierarquia dos elementos WSDL aninhados
que poderiam aparecer em um documento WSDL. Por exemplo, “DescriptionElement”
declara os métodos getinterfaceElements, getBindingElements e
getServiceElements que fornecem acesso ao nível mais alto dos elementos WSDL.
“InterfaceElement” declara os métodos  getInterfaceFaultElements e
getInterfaceOperationElements e assim por diante.

A figura \ref{fig:DiagramaClassesElementModel} representa uma parte do Diagrama
de Classes da API Element, com a classe DescriptionElement se relacionando com
as classes DocumantationElement, IncludeElement, TypesElement, InterfaceElement,
ImportElement, BindingElement e ServiceElement.

\begin{figure}[h]
    \centering
    \includegraphics[width=125mm]{figuras/DiagramaClassesElementModel.png}
    \caption{Diagrama de Classes API Element Woden}
    \label{fig:DiagramaClassesElementModel}
 \end{figure}


\subsubsection{API Component}
A API Component representa o modelo abstrato do Componente WSDL. Ela difere da
API Element em que certos aspectos do WSDL XML não estão representados no
modelo Component. A API Component disponibiliza uma visão com permissão apenas
para leitura do modelo Component do WSDL.  A única forma de se criar o objeto
Description é pela chamada do método toComponent em um objeto
DescriptionElement. Tendo o objeto Description pode-se acessar o resto do
modelo componente do WSDL, porém sem poder modifica-lo. WSDL só pode ser criado
ou modificado por meio da API Element.

A figura \ref{fig:DiagramaClassesComponente} representa uma parte do Diagrama de
classes da API Component, com a classe Descripiton no centro se relacionando com
as classes Services, Interface, TypeDefinition, ElementDeclaretion e Bindings.

\begin{figure}[h]
    \centering
    \includegraphics[width=125mm]{figuras/DiagramaClassesComponente.png}
    \caption{Diagrama de Classes API Component Woden}
    \label{fig:DiagramaClassesComponente}
 \end{figure}


Os principais recursos da API Woden são:

\begin{itemize}
		\item{O mecanismo Factory para a criação de objetos Woden.}
		\item{Configurar o comportamento do Woden definindo características ou
		propriedades do WSDLReader.}
		\item{Personalizar o comportamento no tratamento de erro.}
		\item{Manipulação de modelos de elementos e atributos WSDL baseados em XML.}
		\item{Manipulação de modelos abstratos de componentes WSDL.}
\end{itemize}

A tabela \ref{tab:Mapeamento dos Componentes} ilustra como é tratado o
mapeamento de elementos WSDL para a API.

\begin{table}[h]
	\centering
		\begin{tabular}{|l|l|l|}
		  \hline
		  \multicolumn{3}{|c|}{\textbf{Elementos WSDL}}\\ \hline
		  \textbf{Elemento WSDL} & \textbf{API Element} & \textbf{API Component} \\\hline 
		  <description> & DescriptionElement & Description \\ \hline
          <documentation> &   DocumentationElement & \\\hline
           <import>   &           ImportElement & \\ \hline
           <include> &            IncludeElement & \\ \hline
         <types>        &       TypesElement & \\ \hline
         <interface>     &      InterfaceElement    & Interface \\ \hline 
           <fault> & InterfaceFaultElement  & InterfaceFault \\ \hline 
          <operation> & InterfaceOperationElement  & InterfaceOperation \\\hline 
          <input> & InterfaceMessageReferenceElement & InterfaceMessageReference \\ \hline
          
          <output> & InterfaceMessageReferenceElement &
          InterfaceMessageReference \\ \hline
          
          <infault> & FaultReferenceElement & InterfaceFaultReference \\ \hline 
          
          <outfault> & FaultReferenceElement & InterfaceFaultReference \\ \hline 
          <binding> & BindingElement & Binding \\ \hline
          <fault>  & BindingFaultElement & BindingFault \\ \hline
          <operation> & BindingOperationElement & BindingOperation \\ \hline
         <input> & BindingMessageReferenceElement & BindingMessageReference \\ \hline
         <output> & BindingMessageReferenceElement & BindingMessageReference \\ \hline
            <infault> & FaultReferenceElement & BindingFaultReference \\ \hline
            <outfault> & FaultReferenceElement & BindingFaultReference \\ \hline
            <service> & ServiceElement & Service \\ \hline
           <endpoint> & EndpointElement & Endpoint \\ \hline
         <feature> & FeatureElement & Feature \\ \hline
         <property> & PropertyElement & Property \\ \hline
           \multicolumn{3}{|c|}{\textbf{Elementos XML Schema}}\\ \hline
          <xs:import> & ImportedSchema & \\ \hline
          <xs:schema> & InlinedSchema & \\ \hline
          <xs:element name=``..''> & &ElementDeclaration \\ \hline
          <xs:complexType name=``..''> & & TypeDefinition \\ \hline

         \end{tabular}
		\caption{Mapeamento dos Componentes}
		\label{tab:Mapeamento dos Componentes}
\end{table}

\section {Estrutura lógica do gerador}

O gerador automático de Stubs foi implementado em java com a ajuda da API Apache
Woden, que faz a análise léxica e sintática do WSDL e gera um conjunto de
classes equivalentes para cada elemento do WSDL. Após termos essas classes
mapeadas, foi possível iniciar a fase de desenvolviemnto do processo de
tradução para o JavaScript.

O Gerador é subdividido em duas classes principais: ``LaunchApp'' e
``JSFileStub''. No qual a primeira é a classe principal do gerador e é
a que controla o fluxo de execução do programa. Já a ``JSFileStub'' é o
coração do gerador, onde é feita toda a tradução do WSDL e a geração de códigos
para a montagem da mensagem SOAP para que a integração com o Web Service possa
ser feita.

\section{Geração de Código Auxiliar}

Para que haja a conexão entre o cliente e o servidor, é preciso que o stub
gerado seja capaz de criar mensagens no padrão SOAP empacotando os objetos que
serão enviados para o Web Service. Foi desenvolvido o código em JavaScript capaz
de não só empacotar a mensagem com o padrão SOAP como também ficar responsável
pela requisição ao Web Service e aguardar a mensagem de resposta com as
informações requeridas, para depois transforma-las novamente em objetos
JavaScript.

A classe JSFileStub gera o código responsavel por montar a mensagem SOAP. A
exemplo do que foi explicado na seção \ref{Objetos auxiliares para
comunicação}, são gerados dois objetos responsáveis por esse controle.

\section{Mapeamento para o JavaScript}
Com o WSDL já mapeado para as classes Java como foi visto na seção \ref{Apache Woden},
precisavamos agora escrever toda a tradução para o JavaScript. Definir a
equivalencia de cada elemento WSDL na linguagem alvo. Para isso os elementos
WSDL gerados foram divididos em alguns grupos: Operações, Elementos, Tipos e o
Schema que contem todos os outros três.


\subsubsection{Operations}

As operações são traduzidas, de forma que para se fazer uma chamada a elas, só
é preciso passar como parâmetro a mensagem que deseja enviar e a função de
retorno. A tradução do operations foi feita a partir da definição de um WSDL.
Todas as operações de um WSDL possuem trechos de códigos idênticos mudando
apenas os parâmetros dessas operações. O exemplo abaixo ilusta duas operações
traduzidas do WSDL para o JavaScript:\\

\begin{lstlisting}[style=xml_source_code]
<operation name="TitleCaseWordsWithToken"
    pattern="http://www.w3.org/ns/wsdl/in-out">
    <input messageLabel="In" element="tns:TitleCaseWordsWithToken"/>
    <output messageLabel="Out" element="tns:TitleCaseWordsWithTokenResponse"/>
</operation>    

<operation name="InvertStringCase"
    pattern="http://www.w3.org/ns/wsdl/in-out">
    <input messageLabel="In" element="tns:InvertStringCase"/>
    <output messageLabel="Out" element="tns:InvertStringCaseResponse"/>
</operation> 
   
\end{lstlisting}
    
\begin{lstlisting}[style=xml_source_code]
TitleCaseWordsWithToken: function (body, outMethod) {
    var operation = "TitleCaseWordsWithToken";
    var output = "TitleCaseWordsWithTokenResponse";
    var action = "";
    var outParam = Elements.schema.getAAttr("TitleCaseWordsWithTokenResponse");
    SOAPActions.call(TextCasing.TextCasingSoap.address, 
                     operation, 
                     output,
                     outMethod, 
                     TextCasing.namespace, 
                     action, 
                     true, 
                     body, 
                     outParam,
                     TextCasing.TextCasingSoap.soapVersion); 
},

InvertStringCase: function (body, outMethod) {
    var operation = "InvertStringCase";
    var output = "InvertStringCaseResponse";
    var action = "";
    var outParam = Elements.schema.getAAttr("InvertStringCaseResponse");
    SOAPActions.call(TextCasing.TextCasingSoap.address, 
                     operation, 
                     output,
                     outMethod, 
                     TextCasing.namespace, 
                     action, 
                     true, 
                     body, 
                     outParam,
                     TextCasing.TextCasingSoap.soapVersion); 
},
\end{lstlisting}

Como pode ser visto acima, as duas operações puderam ser escritas com o mesmo
padrão tendo sido diferenciadas apenas pelos seus nomes, tipos de operações e
estruturas de respostas. Com isso, foi possivel mapear todas as operações de um
WSDL de forma automática. 

Para o mapeamento das operações utilizamos a classe Description da API
Component. A partir dela foi possível armazenar todos os serviços em uma
variável do tipo Service[], com isso para cada serviço presente no WSDL o
tradutor monta um objeto com o nome do serviço, com a versão do SOAP e para
cada Endpoint relacionado a esses serviços, o gerador busca o Binding e gera
objetos com todas as operações que esse Binding possui. A figura
\ref{fig:Modelo-Classes-Wsdl} ilustra todas as classes percorridas pelo gerador
para que ele consiga montar todas as operações de cada serviço.

\begin{figure}[h]
    \centering
    \includegraphics[width=30mm]{figuras/Modelo-Classes-Wsdl.png}
    \caption{Representação Java do WSDL}
    \label{fig:Modelo-Classes-Wsdl}
 \end{figure}

\subsubsection{Elementos e Tipos}

A tradução dos elementos e tipos foram feitas a partir da definição de um WSDL.
Todo elemento pode ser do tipo complexo ou simples e possuem algumas variações na forma como
são declarados conforme foi visto na seção \ref{XML}. Com isso, cada elemento
e cada tipo decladrados no WSDL precisam ser mapeados e depois traduzidos para o
Javascript de acordo com as regras próprias do grupo que pertence. O exemplo
abaixo ilusta  a tradução de um elemento com um tipo complexo traduzidos do WSDL
para o JavaScript:\\

\begin{lstlisting}[style = XML_source_code]

<s:element name="EstadosResponse">
        <s:complexType>
          <s:sequence>
               <s:element maxOccurs="1" minOccurs="0" name="EstadosResult"
                type="tns:ArrayOfEstados"/> 
            </s:sequence>
        </s:complexType>
</s:element>

<s:element name="ArrayOfEstados" nillable="true" type="tns:ArrayOfEstados"/>

 <s:complexType name="ArrayOfEstados">
        <s:sequence>
          <s:element maxOccurs="unbounded" minOccurs="0" name="Estados"
           nillable="true" type="tns:Estados"/> 
         </s:sequence>
 </s:complexType>

<s:complexType name="Estados">
        <s:sequence>
          <s:element maxOccurs="1" minOccurs="1" name="ID_Estado" type="s:int"/>
          <s:element maxOccurs="1" minOccurs="0" name="CodigoEstado" type="s:string"/>
          <s:element maxOccurs="1" minOccurs="0" name="Estado" type="s:string"/>
        </s:sequence>
      </s:complexType>
\end{lstlisting}


\begin{lstlisting}[style = js_source_code]


instance.ArrayOfEstados = function(_name) {
			var instance = {};
			instance.inheritFrom = types.WsdlObject;
			instance.inheritFrom(_name, "Complex",undefined);
			instance.addElement(new types.Estados("Estados"));
			return instance;
}

instance.Estados = function(_name) {
			var instance = {};
			instance.inheritFrom = types.WsdlObject;
			instance.inheritFrom(_name, "Complex",undefined);
			instance.addElement(new types.int("ID_Estado"));
			instance.addElement(new types.string("CodigoEstado"));
			instance.addElement(new types.string("Estado"));
			return instance;
}

instance.addElement(new types.ArrayOfEstados("ArrayOfEstados"));

instance.addElement(new function() {
		var instance = {};
		instance.inheritFrom = types.WsdlObject;
		instance.inheritFrom("EstadosResponse", "Complex",undefined);
		instance.addElement(new types.ArrayOfEstados("EstadosResult"));
		return instance;
});




\end{lstlisting}

Como pode ser visto, o elemento ``EstadosResponse'' é composto pelo elemento
``EstadosResult'' que é do tipo complexo ``ArrayOfEstados''. Por sua vez, o
``ArrayOfEstados'' é composto pelo elemento ``Estados'' do tipo ``Estados''.

O gerador primeiramente faz a tradução dos tipos. No exemplo acima, o tipo
``ArrayOfEstados'' sendo declarado como um objeto do tipo ``WsdlObject''
inicializado como complex e possuindo um elemento do tipo Estados no qual a
declaração desse segue o mesmo padrão do tipo que o referenciou.

Após ser feita a tradução de todos os tipos presentes no WSDL, o gerador começa
a montar os elementos. No exemplo acima, são criados dois elementos que
correspondem aos elementos descritos no WSDL. A tabela \ref{tab:XML to
JavaScript} mostra a relação na declaração de um elemento e de um tipo entre o
XML e o JavaScript para facilitar o entendimento do código acima.


% \begin{table}[h]
% 	\centering
% 		\begin{tabular}{|C|l|}
% 		  \hline
% 		    Tag WSDL & Objeto JavaScript \\ \hline
% 			<s:element name=``EstadosResponse''> & instance.addElement(new function()
% 			\\ &              \ldots \\
% 			                   & instance.inheritFrom("EstadosResponse", "Complex",undefined); \\ \hline
% 		    <s:complexType name=``ArrayOfEstados''> & instance.ArrayOfEstados =
% 		    function(\_name) \{ \\ \hline 
% 		\end{tabular}
% 		\caption{XML to JavaScript}
% 		\label{tab:XML to JavaScript}
% \end{table}


Durante a tradução dos tipos, o gerador passa o conteudo de cada tipo para um
método que verifica se o tipo é um complexType ou um simpleType e gera um objeto
JavaScript para cada tipo. 

Para a tradução dos elementos o gerador mantém um comportamento muito parecido,
pois também passa o conteúdo de cada elemento para um método que checa se o
elemento possui o atributo ``name''. Caso o atributo ``name" esteja presente, o
objeto é criado caso contrário o gerador verifica se o próximo nó é uma
instância de um complexType ou simpleType e cria os objetos de acordo com o seu
tipo. Todos os elementos herdam do objeto Types funções para serem inicializados
conforme o  seu tipo correto, se forem Objetos utilizam a função WsdlObject caso
contrario utilizam umas das funções pré definidas que fazem a inicialização de
tipos primitivos.

Para o mapeamento dos elementos e tipos utilizamos a classe Description da API
Component. A partir dela foi possível armazenar todas as definições de tipo que
estão na raiz em uma variável do tipo TypeDefinition[] e as declarações de
elementos em uma variavel do tipo ElementDeclaration[]. A exemplo do que foi
feito durante a tradução das operações o gerador vai descendo na hierarquia até
atingir os nós com as informações necessárias.

\subsubsection{Schema} 
 O Objeto Schema é na verdade o resultado final da tradução e geração de códigos
 auxiliares feitos pelo Gerador Automático de Stubs. Nele se encontram os tipos,
 operações e elementos. A criação de um objeto que encapsulasse todos os outros
 gerados, foi a maneira encontrada para simular uma herança no JavaScript e
 evitar que o mesmo código fosse reescrito diversas vezes sem necessidade. na
 tabela \ref{tab:XML to JavaScript} tem um esquema de como foi mapeado o WSDL
 para o JavaScript.
 
 O fato de todo o código do stub gerado estar contido dendro do objeto Schema
 facilita para o desenvolvedor que pretende utilizar algum Web Service, pois só
 precisará adicionar a sua declaração de script um arquivo.


\begin{flushleft}
\begin{table}[h]
    
	\begin{tabular}{|l|l|}
		  \hline
		    \textbf{Tag WSDL} & \textbf{Objeto JavaScript} \\ \hline
			<{\color{red}description}> & var {\color{red}Schema} = (function()\{ \\\hline
			<{\color{Cyan}types}>  &   var {\color{Cyan}types} = (function ()\{  \\
			\hline <s:{\color{LimeGreen}element} name=``{\color{Green}EstadosResponse}''>
			& instance.{\color{LimeGreen}addElement}(new function() \\ &             
			\ldots \\ & instance.inheritFrom(``{\color{Green}EstadosResponse}'',
			                   {\color{Purple}``Complex''},undefined); \\ \hline 
		  <s:{\color{Purple}complexType} name=``{\color{Gold}ArrayOfEstados}''> &
		  instance.{\color{Gold}ArrayOfEstados} = function(\_name)
		  \{ \\ \hline <service name=``{\color{Magenta}CEPWebService}''> &
		    {\color{Magenta}CEPWebService} = \{ \\ \hline <endpoint
		    name=``{\color{DodgerBlue4} CEPWebServiceSoap}''> &
		    {\color{DodgerBlue4}CEPWebServiceSoap}: \{ \\\hline 
		    <operation name={\color{orange}``ConsultaCEP''}> &  {\color{orange}ConsultaCEP:} function (body, outMethod) \{\\ 
		    <input messageLabel=``In"/> & var operation = {\color{orange}``ConsultaCEP''};\\ 
		    <output messageLabel=``Out'' & var output ={\color{blue}``ConsultaCEPResponse''};\\ 
		      element=``tns: {\color{blue}ConsultaCEPResponse''}/> & var
		      {\color{Firebrick1}action = ``CEP/ConsultaCEP''};\\ 
 	               </operation> & var outParam =
 	               Schema.getAAttr( {\color{blue}``ConsultaCEPResponse''}); \\
 	                                               &SOAPActions.call\\
 	                   <binding name="{\color{DodgerBlue4}CEPWebServiceSoap}"
 	                   &({\color{Magenta}CEPWebService}.{\color{DodgerBlue4}CEPWebServiceSoap}.address,\\
 	                   interface="tns:{\color{DodgerBlue4}CEPWebServiceSoap}"	&
 	                   operation, \\ \ldots     &                  output, \\ <operation ref=``tns:ConsultaCEP'' &  outMethod,\\ 
 	                   wsoap:{\color{Firebrick1}action=``CEP/ConsultaCEP''}>  &
 	                   {\color{Magenta}CEPWebService}.namespace, \\ </operation>   
 	                   &                action, \\ \ldots  &                 true, \\ </binding>   &                 body, \\
 	                            &                outParam,\\ 
 	                            &              
 	                            {\color{Magenta}CEPWebService}.{\color{DodgerBlue4}CEPWebServiceSoap}.soapVersion);\\
 	                            & \},\\\hline
	\end{tabular}
		\caption{XML to JavaScript}
		\label{tab:XML to JavaScript}
\end{table}
 
\end{flushleft}

\section{Problemas Enfrentados}

O primeiro problema encontrado foi o fato de apenas o Internet Explorer suportar
XMLHTTPRequest entre domínios diferentes. Essa função é essencial para a
comunicação com Web Services via AJAX. Essa restrição é devido a política
``Same-origin policy'', no qual após uma conferência de segurança foi acordado
que scripts poderiam executar em páginas originárias de um mesmo domínio e
utilizar livremente métodos e propriedades entre outras páginas, porém não podem
realizar chamadas a métodos e propriedades de domínios diferentes.

Apesar de o gerador estar implemntado de forma que todos os browsers
poderiam utilizar Web Services, pela restrição de ``cross-Domain" as requisições
nao são enviadas nem recebidas com sucesso.

Um segundo ponto de dificuldade foi o fato de no Internet Explorer a API DOM não
dar suporte a namespace. Com isso métodos como getElementsByTagNameNS() e
getAttributerNodeNS()e propriedades como prefix, nameSpaceURI e baseURI não
puderam ser utilizados. Fazendo com que a estratégia para se mapear os elementos
do XML tivesse que ser refeita pois não era possível tratar o namespace da
mensagem SOAP.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%                      Conclus?o                       %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\chapter{Conclusão}
\thispagestyle{empty} 

A proposta do trabalho era implementar um gerador automático de stubs em
JavaScript a partir de um arquivo WSDL, para permitir que
os desenvolvedores de aplicações web que queiram utilizar Web Services em suas
aplicações clientes tenham mais uma linguagem como opção. Além disso, por ser
uma linguagem nativa da web, o JavaScript possibilita uma maior compatibilidade
com os padrões utilizados na web.

O gerador implementado em java faz a tradução de todos os componentes presentes
no WSDL para um arquivo JavaScript o que permite que seja anexado as páginas
web com facilidade. Durante o mapeamento de XML para JavaScript além dos
objetos contendo os elementos usados nas transações, são gerados objetos para
as funções que serão chamadas de forma local e objetos de suporte para que a
mensagem SOAP possa ser montada e enviada para o servidor. Dessa forma o
desenvolvedor utiliza métodos do servidor por meio de Web Services como se
estivesse utilizando apenas funções de um JavaScript local adicionado à página
na declaração dos scripts.

Ao longo do projeto pudemos adquirir uma visão global do mecanismo que envolve a
troca de mensagens sincronas e assincronas por meio de Web Services.Com isso
conseguimos realizar uma engenharia reversa no processo de tradução de um
WSDL para outras linguagens. Essa Engenharia se mostrou essencial para que
fosse possivel a automatização deste processo. Concluimos então que apesar das
dificuldades enfrentadas para a automatização da tradução do WSDL o gerador está
atuando de forma satisfatória e tem boas chances de se tornar util no mercado.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%          Sugest?es para trabalhos futuros            %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\chapter{Sugestões para trabalhos futuros}
\thispagestyle{empty}


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%                  Refer?ncias Bibliogr?ficas                     % 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\begin{thebibliography}{10}
\addcontentsline{toc}{chapter}{Referências Bibliográficas}

\thispagestyle{myheadings}

%referencia pra fazer a bibliografia
%
% http://docs.google.com/viewer?a=v&q=cache:VMlHvJ8PyygJ:biblioteca.planejamento.gov.br/biblioteca-tematica-1/textos/redacao-oficial-e-normalizacao-tecnica-dicas/at_managed_file.2009-10-06.8207989506/+%22referencias+bibliograficas%22&hl=pt-BR&pid=bl&srcid=ADGEESiz98nwxBK8irE9LU7IO7lpGFluqHwGG2pAMy_3cXi86lmZ3XYg55QHc5ngs2oBAxG-N7nVnkzIqAVqpkCbHUABCpf57nYe6VDkV4oKpdS6ziSaP7OvzaEpmLw2JST7WXMwdWhB&sig=AHIEtbR2wtQx1GdmiRop29A2qY5BVlz67Q

\bibitem{livro:buildingwebservices}
        {\textit{Building Web Services -- Sun ONE Studio 5 Programming Service,
        Revision A}, Sun Microsystems, Inc. 2003.}

\bibitem{website:dextra}{\textbf{Dextra} -- Web Services na Integração de
Sistemas Corporativos, \textit{http://www.dextra.com.br/empresa/artigos/webservices.htm}.}

\bibitem{website:w3cnote}{CHRISTENSEN, Erik et al. \textit{Web Services
Description Language (WSDL) 1.1}. Microsoft, IBM Research, 2001.}

\bibitem{atigo:UnderstandingWSDL}{\textbf{Understanding WSDL}, –- Microsoft
Corporation.}
[6] Web Services Description Language (WSDL) Explained - A. M. Software Services, Inc. – Knowledge Base Whitepaper
[7] Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language – W3C Note.
[8] Woden WSDL 2.0 Processor - John Kaputin e Jeremy Huges
[9] http://ws.apache.org/woden - Acessado em 24/06/2010 as 16:00
[10]http://www.slideshare.net/heshans/lexical-analyzers-and-parsers-presentation - Heshan T. Suriyaarachichi - Acessado em 25/06/2010 as 02:00
[11] http://www.w3schools.com/ - Acessado em 15/05/2010 as 22:00


%\bibitem{norma:esjo2005}
%        {Abreu, Estela dos Santos e Teixeira, Jos? Carlos Abreu. 
%        \textit{Apresenta??o de Trabalhos Monogr?ficos de Conclus?o de Curso,
%        8a. edi??o revisada}, EdUFF, 2005.}

%\bibitem{website:ctan}{\textbf{CTAN} (Comprehensive TeX Archive Network),\textit{http://www.ctan.org/}.}
% Este site ? refer?ncia mundial para materiais relacionados ao TeX e LaTeX.

%\bibitem{livro:circuit}{JOHNS, David A. and MARTIN, Ken. \textit{AnalogIntegrated Circuit Design}, John Wiley \& Sons, Inc., 1997.}

%\bibitem{book:signal}{MITRA, Sanjit K. , \textit{Digital Signal Processing - A
%Computer-Based Approach.}, The McGraw-Hill Companies, Inc., 1998.}

\end{thebibliography}

\end{document}


%%%%%%%%%%%%%%%%%
% Fim do modelo %
%%%%%%%%%%%%%%%%%